I hate to say it, but good/useful features like that will be abused by stupid DB guys who can't program.
Hate to burst your bubble, but PostgreSQL's column trigger feature could have actually increased performance many times.
Anything can be abused. Negatively portraying a powerful feature which can dramatically improve performance, readability, and maintainability, in a polithera of use cases, is nothing but FUD and ignorance.
LOL! That's either one of the funniest or most ignorant things stated on/. in a while.
MySQL has a long, long reputation for poor ACID conformance. PostgreSQL, on the other hand, has a long and well respected reputation for both ACID conformance and a variety of lock/update methods which allow for varying degrees of integrity.
i agree completely... when the OP said he would use it "in a lot of scenarios" my red flag of maintainability went up hard.
That's FUD, plain and simple. This is called granularity, not "code scattering." Being able to maintain a trigger which only deals with column x without having to test if your changes break when column y is changed is a big win. Not to mention, you're no longer wasting cycles when column z is updated and x and y are not. Which also means you can throw away traditional CASE code which further improves readability, maintainability, runtime performance, possibly lowers test complexity matrix, and is generally all around good.
What's the difference between logic in the trigger determining when to issue the payload logic, and the logic outside the trigger...
No! Its far more than syntactic sugar. Performance, readability, and maintainability are what this brings to the table.
The difference between PostgreSQL's new column trigger feature and traditional triggers is they are only called when the column is modified rather than when any row is modified. This means, in many cases, the trigger will never be called and therefore, the DB isn't having to run at PL/SQL interpreter speeds during the execution of the trigger, to then determine there is nothing for it to do. Furthermore, a big headache which is extremely common to trigger code are IF/THEN/ELSE or long CASE statements to determine which columns are modified, or to determine if the trigger even cares that the row in question (example, columns which the trigger doesn't care about) has been modified.
The above combination of traditional triggers means lots of overhead, lots of needless PL/SQL code execution, and hard to read/maintain triggers for non-trivial actions. Whereas with the new feature, you can now have a single trigger relate to specific column, which is only ever executed when the trigger should actually execute. Its a win, win, win for all PostgreSQL users. And best of all, this means you can have smaller triggers when you need to perform different actions based on different column changes.
Everything stated is extremely widely known. The fact that you're demanding a citation for what is essentially common knowledge says far, far more about you and how ill equipped you are to be making comments here, on this subject, than anything else.
Soy "milk", on the other hand, is an attempt to replace a great food with a yucky substitute in the name of nutritional "correctness".
I occasionally drink soy milk. It tastes fairly close to milk. If you've tasted different types of milk, you would certainly give soy milk a pass as actually being milk. The taste does differ from brand to brand. After all, there is more in it that just soy juice. In combination with other cereal products, most people can't taste the difference; especially if you use sugary cereal.
As for the "great food" comment. Actually, milk is a poor choice unless you're an infant. And even for infants, cow milk is a poor substitute. Humans should consume human milk and cows should consume cow milk. And technically, goat's milk is actually better for you than cows milk. Around the world, goats and sheep provide the majority of the world's milk supply consumed by humans. And this entirely ignores the fact that most consumer milks have many substances which are out right bad for humans; including antibiotics and hormones. Both of which has been shown to cause endless problems for lower forms of life. Likewise, many studies have shown some correlation between consumption of these substances and health problems in humans, not to mention playing a role in antibiotic immunity is various pathogens.
And even within milk, the taste can vary dramatically; including human milk. As with most mammals, a milk's flavor is frequently characterized by both the species of mammal and the diet consumed by the milk producing mammal.
So basically your complaint boils down to: I don't like anything other than unhealthy cow's milk because alternatives taste different and are typically far more healthy.
As a side note, you can frequently get soy milk in a variety of flavors. So if you don't like the taste of straight soy milk, try a flavored variety which is far less likely to confuse your milk-biased buds. Many people enjoy vanilla. But if soy is flat out not your thing, there are a variety of alternate "milk" products which are derived from a multitude of different nuts, most of which are more healthy than cows milk when it comes to human consumption.
This is not a parser error. If it were, it would be impossible for IE's JS to ever produce code which can perform. So your argument is its obviously a simple bug which destroyed JS performance, which is likely to effect any and all JS code and yet they are somehow able to pull of super fast optimizations which are specific to a benchmark and seemingly beyond the ability of any other JS engine.
Or, we can make the obvious assumption. Others are frequently caught at cheating in benchmarks. Obviously MS go caught cheating. Obviously MS cheats. Either that, or according to you, they have some really horrible bugs which means its impossible they could perform so well in every other use.
Uhh...the person who documented the test drew the exact same conclusion I did. That's entirely his point. The only difference is he was politically correct and didn't state the obvious conclusion - my conclusion, which I did state.
Basically you're arguing that you're right because you're wrong. Brilliant.
Maybe the only "problem" is that IE's JS engine saw though the test, said, "hm, this code doesn't do jack" and skipped it.
LOL! Brilliant deduction. No wonder you didn't understand in the least what you read. Allow me to explain it to you since you very clearly must have it explained to you.
If IE's JS is so awesome, it would have optimized away nop instructions and returned the exact same result with the same runtimes. That's entirely the point. Meaning, the test proves this wasn't the result of some super smart IE optimization. Rather, the only possible result is IE specifically looks for that test and returns a canned result. Minor, completely useless changes to the test complete screw up IE's benchmark detection which prevents it from cheating. As a result, operations which should have zero effect result in IE performing 20x slower that its cheat otherwise provides. Meaning, when it actually executes, rather than cheats, its 20x slower. That's the only possible conclusion.
The JS engine's optimizer should see exactly ZERO differences in the generated code. The addition of an explicit "return" vs an implicit "return" is absolutely proof this is not optimization trickery.
In other words, the ONLY POSSIBLE CONCLUSION is exactly as I depicted and exactly as IE troll moderators are working so hard to hide via their false, trollish moderations.
it definitely doesn't accuse Microsoft of cheating. Nor do any of the comments. So I think you're blowing it out of proportion.
Excuse me for drawing the only possible conclusion and stating it here. Silly me for assuming readers of a technology centric website would be able to reach the same, obvious, and sole conclusion.
Basically, if you did not reach said conclusion, slashdot is over your head. And the moderators are fucking insane. Offtopic this for completely on topic posts. And flaimbait that for polite replies.
Fucking troll moderators and showing their stupidity like crazy today - as is the slashdot reading/posting population.
Why are you so angry about a post which was clearly opinion and then clearly followed up with stating it was completely anecdotal? Even moreso, why did you reply when absolutely no reply was required in the first place, let alone a series of absolutely pointless replies.
Not that 1.6 is inherently more reliable than 2.2.
Actually, its a fact that all devices prior to Android 2.x have a fundamental OS flaw and are inherently less reliable. Android 2.2 adds limited JIT capability to the platform, fixes various life cycle problems which still existed at the start of the 2.x series (which is one of the reasons why 2.x is fundamentally broken), and goes a long way toward improvement memory management.
In a nutshell, all devices running Android prior to 2.01 have fatal life cycle, memory and resource management flaws.
In fact, one of the reasons why task killers briefly became popular on Android is exactly because of these horrible OS flaws; which I previously blamed on applications. Task killers are not only no longer needed, but they don't even work on Android 2.2 and later. The fact of the matter is, while many of the problems I blamed on applications were in fact application problems, many were not or were a compounding of application and OS bugs/flaws.
How is it confirming what I said, "not even remotely what the glob post actually says." It clearly documents IE returning a completely bogus result clocking in at over 20x what it can actually run. There is even a graphic.
I suggest you re-read the link because your post does "not even remotely [reflect] what the glob post actually says."
Read the whole thing already. That's two replies from two people who didn't even read the damn link. There is even a graphic. Just read the article rather than pretend you did.
Oddly enough, someone in this same thread made reference to that same 10%. Even 10% still qualifies it as a fringe so this isn't exactly an ego driven position.
All I know is, everywhere I go I constantly see desktop adoption rates much higher than 2%. Sure that's anecdotal but anecdotally, its seems to consistently correspond with that 10%. Think about it. At 2%, you would almost never see Linux on desktops and yet I commonly see it. Realistically, the 2% number is a complete guess and yet everyone throws it around as if its fact. Its hardly a reach to presume someone's guess is a bit on the low side. To say the accurate number is somewhere between 2% and 10% is extremely likely where the truth exists.
Now if we're talking Linux desktops which game companies might care about, it probably is closer to 2%, or less.
I recently read an article, which I can't seem to find, which purports Linux accounts for roughly 10% of desktops. I find this to be far more likely than the often quoted 2%. People forget that desktop doesn't always translate into web browser. And given the frequent niches Linux fills, its far more likely for a Linux desktop to exist which is never accounted for by web statistics.
Realistically, due to Linux's nature, we have absolutely no idea how many Linux desktops there really are. And likely, anyone who says they have a precise number is selling statistics. The only thing I am sure of, the desktop counts for Linux are extremely likely to be far larger than the often quoted 2%.
Until Microsoft stops purposely misleading people with their completely bogus benchmark results, their stigma of poor quality and low performance is nothing but well deserved.
I think its wonderful that someone who clearly didn't read the article and made a nonsense comment based on a lack of knowledge gets moderated, "insightful". I would like to subscribe to your news letter. Obviously I won't actually read it, but when I comment on random topics after receiving your news letter, I presume others will believe me to be extremely insightful.
I'm honestly not sure which is worse, your "best effort" comment or the "best effort" moderator.
Because we know he didn't. He gave himself access to COMPANY DATA and contacted people using a COMPANY SERVICE, using access granted by that very same company. Unless you have some legal reason which can establish an employee accessing company property, to which the company granted access, is illegal, we have nothing more to discuss. Violation of company policy is not a crime.
The fact you suggest this needs to go in front of police or a judge to determine legality is brain numbingly dumb. To suggest such a thing implies you believe companies, literally, now write laws for everyone. Not only that, but using your logical, almost every employed person in the world is likely guilty of violating a law. Let's start parading them in front of police and judges to see if we can make something, anything, stick.
Slashdot Mirror
I hate to say it, but good/useful features like that will be abused by stupid DB guys who can't program.
Hate to burst your bubble, but PostgreSQL's column trigger feature could have actually increased performance many times.
Anything can be abused. Negatively portraying a powerful feature which can dramatically improve performance, readability, and maintainability, in a polithera of use cases, is nothing but FUD and ignorance.
LOL! That's either one of the funniest or most ignorant things stated on /. in a while.
MySQL has a long, long reputation for poor ACID conformance. PostgreSQL, on the other hand, has a long and well respected reputation for both ACID conformance and a variety of lock/update methods which allow for varying degrees of integrity.
The fact he makes such a statement means two things. One, he's never bothered to look. Two, only interested in FUD'ing.
i agree completely... when the OP said he would use it "in a lot of scenarios" my red flag of maintainability went up hard.
That's FUD, plain and simple. This is called granularity, not "code scattering." Being able to maintain a trigger which only deals with column x without having to test if your changes break when column y is changed is a big win. Not to mention, you're no longer wasting cycles when column z is updated and x and y are not. Which also means you can throw away traditional CASE code which further improves readability, maintainability, runtime performance, possibly lowers test complexity matrix, and is generally all around good.
What's the difference between logic in the trigger determining when to issue the payload logic, and the logic outside the trigger...
No! Its far more than syntactic sugar. Performance, readability, and maintainability are what this brings to the table.
The difference between PostgreSQL's new column trigger feature and traditional triggers is they are only called when the column is modified rather than when any row is modified. This means, in many cases, the trigger will never be called and therefore, the DB isn't having to run at PL/SQL interpreter speeds during the execution of the trigger, to then determine there is nothing for it to do. Furthermore, a big headache which is extremely common to trigger code are IF/THEN/ELSE or long CASE statements to determine which columns are modified, or to determine if the trigger even cares that the row in question (example, columns which the trigger doesn't care about) has been modified.
The above combination of traditional triggers means lots of overhead, lots of needless PL/SQL code execution, and hard to read/maintain triggers for non-trivial actions. Whereas with the new feature, you can now have a single trigger relate to specific column, which is only ever executed when the trigger should actually execute. Its a win, win, win for all PostgreSQL users. And best of all, this means you can have smaller triggers when you need to perform different actions based on different column changes.
Well said!
Do I need a citation that 1+1=2?
Everything stated is extremely widely known. The fact that you're demanding a citation for what is essentially common knowledge says far, far more about you and how ill equipped you are to be making comments here, on this subject, than anything else.
Soy "milk", on the other hand, is an attempt to replace a great food with a yucky substitute in the name of nutritional "correctness".
I occasionally drink soy milk. It tastes fairly close to milk. If you've tasted different types of milk, you would certainly give soy milk a pass as actually being milk. The taste does differ from brand to brand. After all, there is more in it that just soy juice. In combination with other cereal products, most people can't taste the difference; especially if you use sugary cereal.
As for the "great food" comment. Actually, milk is a poor choice unless you're an infant. And even for infants, cow milk is a poor substitute. Humans should consume human milk and cows should consume cow milk. And technically, goat's milk is actually better for you than cows milk. Around the world, goats and sheep provide the majority of the world's milk supply consumed by humans. And this entirely ignores the fact that most consumer milks have many substances which are out right bad for humans; including antibiotics and hormones. Both of which has been shown to cause endless problems for lower forms of life. Likewise, many studies have shown some correlation between consumption of these substances and health problems in humans, not to mention playing a role in antibiotic immunity is various pathogens.
And even within milk, the taste can vary dramatically; including human milk. As with most mammals, a milk's flavor is frequently characterized by both the species of mammal and the diet consumed by the milk producing mammal.
So basically your complaint boils down to: I don't like anything other than unhealthy cow's milk because alternatives taste different and are typically far more healthy.
As a side note, you can frequently get soy milk in a variety of flavors. So if you don't like the taste of straight soy milk, try a flavored variety which is far less likely to confuse your milk-biased buds. Many people enjoy vanilla. But if soy is flat out not your thing, there are a variety of alternate "milk" products which are derived from a multitude of different nuts, most of which are more healthy than cows milk when it comes to human consumption.
First time I've ever seen Hulu actually work. The 64-bit Linux plugin works like a charm with Hulu!
This is not a parser error. If it were, it would be impossible for IE's JS to ever produce code which can perform. So your argument is its obviously a simple bug which destroyed JS performance, which is likely to effect any and all JS code and yet they are somehow able to pull of super fast optimizations which are specific to a benchmark and seemingly beyond the ability of any other JS engine.
Or, we can make the obvious assumption. Others are frequently caught at cheating in benchmarks. Obviously MS go caught cheating. Obviously MS cheats. Either that, or according to you, they have some really horrible bugs which means its impossible they could perform so well in every other use.
Holy shit. Dumber than a bag of hammers.
As did the person who *actually ran the tests
Uhh...the person who documented the test drew the exact same conclusion I did. That's entirely his point. The only difference is he was politically correct and didn't state the obvious conclusion - my conclusion, which I did state.
Basically you're arguing that you're right because you're wrong. Brilliant.
Maybe the only "problem" is that IE's JS engine saw though the test, said, "hm, this code doesn't do jack" and skipped it.
LOL! Brilliant deduction. No wonder you didn't understand in the least what you read. Allow me to explain it to you since you very clearly must have it explained to you.
If IE's JS is so awesome, it would have optimized away nop instructions and returned the exact same result with the same runtimes. That's entirely the point. Meaning, the test proves this wasn't the result of some super smart IE optimization. Rather, the only possible result is IE specifically looks for that test and returns a canned result. Minor, completely useless changes to the test complete screw up IE's benchmark detection which prevents it from cheating. As a result, operations which should have zero effect result in IE performing 20x slower that its cheat otherwise provides. Meaning, when it actually executes, rather than cheats, its 20x slower. That's the only possible conclusion.
The JS engine's optimizer should see exactly ZERO differences in the generated code. The addition of an explicit "return" vs an implicit "return" is absolutely proof this is not optimization trickery.
In other words, the ONLY POSSIBLE CONCLUSION is exactly as I depicted and exactly as IE troll moderators are working so hard to hide via their false, trollish moderations.
it definitely doesn't accuse Microsoft of cheating. Nor do any of the comments. So I think you're blowing it out of proportion.
Excuse me for drawing the only possible conclusion and stating it here. Silly me for assuming readers of a technology centric website would be able to reach the same, obvious, and sole conclusion.
Basically, if you did not reach said conclusion, slashdot is over your head. And the moderators are fucking insane. Offtopic this for completely on topic posts. And flaimbait that for polite replies.
Fucking troll moderators and showing their stupidity like crazy today - as is the slashdot reading/posting population.
No. It was an independent blog.
Why are you so angry about a post which was clearly opinion and then clearly followed up with stating it was completely anecdotal? Even moreso, why did you reply when absolutely no reply was required in the first place, let alone a series of absolutely pointless replies.
Seems your name is well chosen.
As was stated in the post; there should be little if any variance.
Not that 1.6 is inherently more reliable than 2.2.
Actually, its a fact that all devices prior to Android 2.x have a fundamental OS flaw and are inherently less reliable. Android 2.2 adds limited JIT capability to the platform, fixes various life cycle problems which still existed at the start of the 2.x series (which is one of the reasons why 2.x is fundamentally broken), and goes a long way toward improvement memory management.
In a nutshell, all devices running Android prior to 2.01 have fatal life cycle, memory and resource management flaws.
In fact, one of the reasons why task killers briefly became popular on Android is exactly because of these horrible OS flaws; which I previously blamed on applications. Task killers are not only no longer needed, but they don't even work on Android 2.2 and later. The fact of the matter is, while many of the problems I blamed on applications were in fact application problems, many were not or were a compounding of application and OS bugs/flaws.
How is it confirming what I said, "not even remotely what the glob post actually says." It clearly documents IE returning a completely bogus result clocking in at over 20x what it can actually run. There is even a graphic.
I suggest you re-read the link because your post does "not even remotely [reflect] what the glob post actually says."
Read the whole thing already. That's two replies from two people who didn't even read the damn link. There is even a graphic. Just read the article rather than pretend you did.
Read my follow up reply above.
The answer is no, because it fits with my observed, anecdotal results.
Why do you doubt it, because it fits with your biases?
No need to answer. Here's a hint. Its a dumb question.
Oddly enough, someone in this same thread made reference to that same 10%. Even 10% still qualifies it as a fringe so this isn't exactly an ego driven position.
All I know is, everywhere I go I constantly see desktop adoption rates much higher than 2%. Sure that's anecdotal but anecdotally, its seems to consistently correspond with that 10%. Think about it. At 2%, you would almost never see Linux on desktops and yet I commonly see it. Realistically, the 2% number is a complete guess and yet everyone throws it around as if its fact. Its hardly a reach to presume someone's guess is a bit on the low side. To say the accurate number is somewhere between 2% and 10% is extremely likely where the truth exists.
Now if we're talking Linux desktops which game companies might care about, it probably is closer to 2%, or less.
Absolutely do not include Sunspider in the results as Mozilla has caught Microsoft (IE) cheating. They are actively detecting these benchmarks are falsely providing results up to twenty times faster than they are able to actually execute the code. The only reason they got caught was because one benchmark was so much faster than what everyone else was doing and the nature of the benchmark seemed unlikely anyone would have such a significant advantage.
IE + Sunspider = absolute lies. The results are rigged.
The later two are far more likely to provide meaningful results. And Kraken is specifically designed to reflect exactly that.
I recently read an article, which I can't seem to find, which purports Linux accounts for roughly 10% of desktops. I find this to be far more likely than the often quoted 2%. People forget that desktop doesn't always translate into web browser. And given the frequent niches Linux fills, its far more likely for a Linux desktop to exist which is never accounted for by web statistics.
Realistically, due to Linux's nature, we have absolutely no idea how many Linux desktops there really are. And likely, anyone who says they have a precise number is selling statistics. The only thing I am sure of, the desktop counts for Linux are extremely likely to be far larger than the often quoted 2%.
And it doesn't help that the mozilla team recently identified IE as detecting various benchmarks to make IE look up to twenty times faster than it really is.
Until Microsoft stops purposely misleading people with their completely bogus benchmark results, their stigma of poor quality and low performance is nothing but well deserved.
I think its wonderful that someone who clearly didn't read the article and made a nonsense comment based on a lack of knowledge gets moderated, "insightful". I would like to subscribe to your news letter. Obviously I won't actually read it, but when I comment on random topics after receiving your news letter, I presume others will believe me to be extremely insightful.
I'm honestly not sure which is worse, your "best effort" comment or the "best effort" moderator.
How do you know he didn't commit a crime?
Because we know he didn't. He gave himself access to COMPANY DATA and contacted people using a COMPANY SERVICE, using access granted by that very same company. Unless you have some legal reason which can establish an employee accessing company property, to which the company granted access, is illegal, we have nothing more to discuss. Violation of company policy is not a crime.
The fact you suggest this needs to go in front of police or a judge to determine legality is brain numbingly dumb. To suggest such a thing implies you believe companies, literally, now write laws for everyone. Not only that, but using your logical, almost every employed person in the world is likely guilty of violating a law. Let's start parading them in front of police and judges to see if we can make something, anything, stick.