select count(*) from tablename or select count(fieldname) from tablename
This is incredibly slow as PostgreSQL scans the entire table! I know there are work arounds that will return approximate but this isn't good enough. I keep hearing how it isn't possible, that the table stats can't be updated etc... but other DB's handle this extremely fast.
Yeah, MySQL handles it really well... by giving you an approximation!
I was a big fan... until I needed to use PostgreSQL 7 for a real (commercially available) product. To call it slow would be an abomination of the word. Slow doesn't even begin to describe b-tree insert times. Yes, I tuned the engine and dropped indexes at the appropriate times. Yes, my data structures were relational. Yes, this contradicts some published benchmarks. My use is real world and in reality, PostgreSQL is slow... and a bit buggy.
Absolute bullshit. I've used PostgreSQL myself in a mission-critical production app for the past 3 years. (I've since left the company, but the app is still in use.) I have been consistently impressed by the quality and performance. There was a strong push to use mysql when the project started since the company already had in-house knowledge of it. Performance was one of the concernes. So I ran the benchmarks. Read performance of simple selects was inconclusive: mysql won some, and postgresql won some. However, postgresql consistently won write tests and scaled better as I added more client threads.
Nested parentheses in SQL can cause an engine crash. " like... (SELECT A INNER JOIN B) INNER JOIN..." But the crashing is tolerable. Hand-holding the query optimizer is not. Quite often, the optimizer gets the query plan wrong. Sending special commands to disable internal features is often the only resort.
Bullshit again. Never ever seen that or even heard about it. Again, at my last job postgresql was part of a mission-critical application, and I've used it for a couple of projects before that too. The *only* time I've seen postgresql go down was when we ran out of disk space. And even then, it was not a crash but a clean shutdown. Give me a specific example of a query that you say caused postgresql to crash. Otherwise I'll assume you are yet another troll.
While it's true that PostgreSQL is more database than most corporate weenies need, it falls down in moderate write environments. It's best used for systems that write data very infrequently, otherwise it fragments quickly. The only solution to table and database fragmentation is dump & reload.
Bullshit 3x. The app I was talking about was used for tracking work in a 3d production pipeline with a staff of ~300 artists. There was *a lot* of writes. (every checkin, every render, etc.) By the end of the project the database grew to over 10G. And postgresql didn't even blink.
Vacuum is asinine. Any command that needs to be run periodically under threat of complete and total data corruption should not be. That's right. Only PostgreSQL makes you vacuum or else your transaction ids overflow. This is modern? I'm shocked.
And your point is? All it requires is a single entry in crontab. And you can still run transactions while it's vacuuming. Really, what is your problem with it? It is no different than running a cronjob to do a backup, or a similar maintenance. And since 8.0 and up, postgresql does autovacuum, so you don't even have to worry about that.
So, in short, from my experience PostgreSQL Just Works (TM). And unlike oracle it doesn't cost an arm and a leg, and doesn't require an army of DBAs and sysadmins to maintain it.
Once again, slashdot summary is wrong and you didn't read the article.
Ideally, a judge would, like the article's author, take one look at the charges and say, "whaaaaat?" just before throwing the whole silly thing out. Now three loops have decided returning the drive clean is a crime, unanimously.
RTFA. That's exactly what the judge did. The company appealled the decision, and the appeals court sent it back to the judge saying: no, you can't throw this out. The company might be right. You need to hold a trial to figure it out.
Having read the article, I agree. The issue is not so clear-cut that it should be dismissed out of hand: it deserves its day in court. The guy may have deleted incriminating information (which is a crime, see Enron paper shredders). He may also have been propping up his business at company's expense (i.e. using whatever data he acquired while making sure the company doesn't get a hold of it). That's for the judge to decide, and that's exactly what the appeals court said should happen.
I'm surprised no one has mentioned it yet, but the big advantage comes from removing *two* convertion steps when you use a UPS. Normally a power supply takes AC current and converts it to DC. A UPS does the same thing: takes AC power and converts it to DC to charge the battery. But then it takes the DC current out of the battery and converts it back to AC so that you can plug the power supply into it! So effectively we get AC -> DC -> AC -> DC. Obviously this is stupid since you waste some energy with each convertion. When you have whole racks of computers and network equipment all plugged into a UPS, it would be much more efficient if they could accept DC current coming out of UPS. Then they wouldn't even need power supplies since they wouldn't need to convert current. *That* is why DC equipment is more efficient. Of course the article didn't explain that.
Your CDs are being taxed just like in Canada. Except that you don't even get the right to copy with that -- so the tax is pure profit for the record labels. Now you'd better start protesting.
What's that? All talk and no action? How typical...
Just by glancing at the list I also found the following:
FreeBSD
NetBSD
OpenBSD
SGI Irix
That means the "UNIX/Linux" category is at least 10 OSes. On top of that, there is this gem:
The end-of-year vulnerability score should be taken with a grain of salt, however, since US-CERT doesn't filter out updates (so one actual vulnerability can be counted numerous times) nor does it break out individual vulnerabilities from warnings that cover multiple bugs (as in the many Mac OS X vulnerability listings).
Yep. Another bullshit number designed only to spread FUD.
Gates was emphatically impressed with India's human resource saying, "India has a fantastic pool of software professionals. The world needs to benefit from this. I never thought with so little product companies software services sector will grow so strong as it has grown here."
Yeah, I'm sure this has nothing to do with India's move to open source software. And I'm sure Microsoft's investment will in no way affect the government's decision. No sir.
I stopped reading right there. What a load of crap. It's roughly 50$ for Windows XP Home and 100$ for MS Office.
Did you pull these numbers out of your ass, microshill? Let's see, windows XP professional OEM costs $146.95. You can get a slight discount by buying a 30-pack for $4,249.95. A pre-installed version from a Dell or HPaq (without the media, so you can't reinstall and configure it yourself) would cost a little less, but certainly nowhere near $50.
Office 2003 professional (again, OEM, not retail) costs $319.95. Yes, it's also a little cheaper from a big vendor but nowhere near $100.
Please show me where you can buy windows for $50 and office for $100.
You obviously have never worked on large server-side applications. Other posters have already listed some reasons for java's popularity. I'll add some more:
* java is nearly as fast as C++ according to all the benchmarks I've seen. Yes, really. The perception of java as being "slow" is simply the legacy of the old awt apps. Yes, the awt gui was (and is) slow. Server-side java applications are not. The "much better performance" is simply not there, particularly for typical enterprise apps.
* *All* the enterprise apps (which is the area where java is particularly successful) store stuff in a database and/or talk to remote apps. Newsflash: a database query or a remote procedure call is *orders of magnitude slower* than an in-process procedure call. Once you include DB/RPC into the equation, whatever little speed advantage C++ has is wiped out completely.
* This is CS 101: performance of a program is largely determined by the algorithm used. You can write a linear search in assembly, and it will be very fast for small lists. But for large lists, a binary search written in shell script will beat it.
* In an enterprise application scalability is much more important than raw speed. So what if I can write a C++ app that's 20% faster than an equivalent java app? Java has frameworks that make it easy to write an app that you can scale horizontally (i.e. by adding more boxes). Easy being the keyword.
* Developer's time is much more expensive than runtime. It is *much faster* to write an app in java than in C++. And for all but the smallest/simplest apps it is faster to write the app in java than in PHP/perl/whatever.
If it's a safety/security issue then again you could build the same thing in a native compiled language, sandbox and all.
Uhhhm, yes. Safety and security are *big* issues in enterprise apps. Show me *one* native language and platform that does it. You are saying it like one can just wave a magic wand and have it built in no time. "You could build the same thing" is not "it's already built".
I mean really, is it just because Java provides a lot of easy to use API's?
Yes. among all the other things I've mentioned.
These are just a few reasons why java is so popular in enterprise apps. Sure, I wouldn't write a game in java, but for enterprise apps, it's perfect. Why java and not PHP/perl/? Simply because java is better. It has all the advantages of compiled laguages (type safety, variable declaration checking, syntax checking, etc.) without some of the disadvantages (manual memory management). Think of java compiler as a sanity checker for your code. It will catch common mistakes like typos, missing return statements, invalid function parameters, etc. A scripting language will not complain about that, but force you to spend hours tracking down the bug. That's why java is faster to develop in than any scripting language for large apps.
- buy a 20GB iPod - buy a 80GB 1.8" HD - upgrade the HD in the iPod
This would be awesome if you fill up the HD but don't want to shell out $$$ for a whole new unit. Is this possible? I'd love to buy a 20GB model knowing that if I ever run out of space I can upgrade the HD.
In all this open source/closed source voting debate people completely miss the more important question: *why* are you pushing for voting machines in the first place? What problem are you trying to solve?
As a Canadian, I am completely baffled by our neighbours south of the border. Here in Canada, the *entire country* uses identical paper ballots and it works beautifully. Nothing can be more simple, transparent and verifiable than that.
Let me give you an example I really like. Back in 2000, Canadian federal election was called at the end of november, so it occured a few weeks after the US election. We knew the results the next morning (or, those who cared to stay up late, knew it the same day). In the meantime, our friends south of the border were still counting pregnent chads and butterfly ballots. At that point everyone went "huh? *that* is the world's greatest democracy?"
So seriously guys, what problem are you trying to solve with punch cards and computers? It clearly can't be the scale. Canada has twice the population of Florida and way more political parties. Convenience? No, can't be that either. One of the problems in Florida was that the voters found the butterfly ballots confusing. Speed of counting? No, can't be that. Canada, with twice the population and much greater voter turnout, managed to count all the ballots by hand in a few hours after the polls closed. So... uhhh.... what?
The way I see it, anything other than paper ballots serves only to obuscate voting and provide pork barrel for corporations that "donate" enough money. Electronic voting machines make the problem much worse. If there is no physical record of a vote, fraud and vote tampering is ridiculously easy. Think about it: how can you trust that a computer will add 1 vote to your candidate when you press the button? A group of security researchers have answered that question: you can't. Voting machines must contend with two conflicting requirements: verifiability and voter anonymity. Therefore, the only machine that provably satisfies both requirements is one that prints out a piece of paper that you deposit into the ballot box. In other words, a machine that acts as nothing more than a high-tech pencil. Whoop-deee-dooo! big progress!
So anyway, while open source voting machines are "better", they still don't solve the root of the problem: electronic voting reduces transparency and simplifies vote tampering. The proper solution solution is to go back to paper and pencil. But no, we can't have that. That would be admitting a mistake. And USians never make mistakes. Besides, paper & pencil is only used in those backwards uncivilized countries like Canada, Britain, Germany, France, Japan, etc. We are all k00l and high-tech and stuff!!!
I have no clue what I'm doing, but I'm considering getting some apples. One of my buddies actually likes apples. I've never tried them but I like oranges. Are there any benefits of apples over oranges?
Rendering farm: Your CG movie is due to premiere next month, and your 10,000-node rendering farm can complete the job in time. Wouldn't you pay extra $$ to anyone who can save the day and guarantee that screenshots won't be leaked to the Net ?
And how the fuck are you going to transfer *hundreds of gigabytes* of data required to render a frame over the internet? How are you going to receive the data back? (2MB - 12MB per layer per frame).
Does that thing even have Renderman installed? (at $5k/CPU I highly doubt it). Does it have Shake? Does it have Houdini? Does it have Maya?
Besides that, how the fuck are you going to get approval to send _anything_ out of the studio? You obviously have never worked in the industry.
I'm also skeptical as to whether there is any use for this. What sort of environment do they run it on? Solaris/SPARC? Solaris/x86? Linux? Windows? What sort of software does it have installed? Would it ever be possible to replicate the in-house environment on this "grid"? (you know, with all the custom software, directory structure, environment variables, aliases, etc.) I know for a fact that there is no way we could outsource our rendering to Sun even if we tried.
The whole "CPU-hour" thing is a very nebulous concept. Environments differ wildly from one company to another, so you can never have a universal "CPU grid" in the same sense as you can have an electric grid.
The whole point of HDCP is that there is *nothing* between the "protected" content and the output device that could be used to retrieve the decrypted signal. Your dongle could be connected to some sort of recorder instead of the monitor, making the end-to-end encryption useless.
Slashdot Mirror
Yeah, MySQL handles it really well... by giving you an approximation!
Absolute bullshit. I've used PostgreSQL myself in a mission-critical production app for the past 3 years. (I've since left the company, but the app is still in use.) I have been consistently impressed by the quality and performance. There was a strong push to use mysql when the project started since the company already had in-house knowledge of it. Performance was one of the concernes. So I ran the benchmarks. Read performance of simple selects was inconclusive: mysql won some, and postgresql won some. However, postgresql consistently won write tests and scaled better as I added more client threads.
Nested parentheses in SQL can cause an engine crash. " like ... (SELECT A INNER JOIN B) INNER JOIN ..." But the crashing is tolerable. Hand-holding the query optimizer is not. Quite often, the optimizer gets the query plan wrong. Sending special commands to disable internal features is often the only resort.
Bullshit again. Never ever seen that or even heard about it. Again, at my last job postgresql was part of a mission-critical application, and I've used it for a couple of projects before that too. The *only* time I've seen postgresql go down was when we ran out of disk space. And even then, it was not a crash but a clean shutdown. Give me a specific example of a query that you say caused postgresql to crash. Otherwise I'll assume you are yet another troll.
While it's true that PostgreSQL is more database than most corporate weenies need, it falls down in moderate write environments. It's best used for systems that write data very infrequently, otherwise it fragments quickly. The only solution to table and database fragmentation is dump & reload.
Bullshit 3x. The app I was talking about was used for tracking work in a 3d production pipeline with a staff of ~300 artists. There was *a lot* of writes. (every checkin, every render, etc.) By the end of the project the database grew to over 10G. And postgresql didn't even blink.
Vacuum is asinine. Any command that needs to be run periodically under threat of complete and total data corruption should not be. That's right. Only PostgreSQL makes you vacuum or else your transaction ids overflow. This is modern? I'm shocked.
And your point is? All it requires is a single entry in crontab. And you can still run transactions while it's vacuuming. Really, what is your problem with it? It is no different than running a cronjob to do a backup, or a similar maintenance. And since 8.0 and up, postgresql does autovacuum, so you don't even have to worry about that.
So, in short, from my experience PostgreSQL Just Works (TM). And unlike oracle it doesn't cost an arm and a leg, and doesn't require an army of DBAs and sysadmins to maintain it.
So if they can make fuel cells for ficken *laptops* why can't they do the same thing for cars??
Ideally, a judge would, like the article's author, take one look at the charges and say, "whaaaaat?" just before throwing the whole silly thing out. Now three loops have decided returning the drive clean is a crime, unanimously.
RTFA. That's exactly what the judge did. The company appealled the decision, and the appeals court sent it back to the judge saying: no, you can't throw this out. The company might be right. You need to hold a trial to figure it out.
Having read the article, I agree. The issue is not so clear-cut that it should be dismissed out of hand: it deserves its day in court. The guy may have deleted incriminating information (which is a crime, see Enron paper shredders). He may also have been propping up his business at company's expense (i.e. using whatever data he acquired while making sure the company doesn't get a hold of it). That's for the judge to decide, and that's exactly what the appeals court said should happen.
Oh and, btw:
Adolf Hitler
you lose.
I'm surprised no one has mentioned it yet, but the big advantage comes from removing *two* convertion steps when you use a UPS. Normally a power supply takes AC current and converts it to DC. A UPS does the same thing: takes AC power and converts it to DC to charge the battery. But then it takes the DC current out of the battery and converts it back to AC so that you can plug the power supply into it! So effectively we get AC -> DC -> AC -> DC. Obviously this is stupid since you waste some energy with each convertion. When you have whole racks of computers and network equipment all plugged into a UPS, it would be much more efficient if they could accept DC current coming out of UPS. Then they wouldn't even need power supplies since they wouldn't need to convert current. *That* is why DC equipment is more efficient. Of course the article didn't explain that.
Your CDs are being taxed just like in Canada. Except that you don't even get the right to copy with that -- so the tax is pure profit for the record labels. Now you'd better start protesting.
What's that? All talk and no action? How typical...
That means the "UNIX/Linux" category is at least 10 OSes. On top of that, there is this gem:
The end-of-year vulnerability score should be taken with a grain of salt, however, since US-CERT doesn't filter out updates (so one actual vulnerability can be counted numerous times) nor does it break out individual vulnerabilities from warnings that cover multiple bugs (as in the many Mac OS X vulnerability listings).
Yep. Another bullshit number designed only to spread FUD.
Yeah, I'm sure this has nothing to do with India's move to open source software. And I'm sure Microsoft's investment will in no way affect the government's decision. No sir.
Did you pull these numbers out of your ass, microshill? Let's see, windows XP professional OEM costs $146.95. You can get a slight discount by buying a 30-pack for $4,249.95. A pre-installed version from a Dell or HPaq (without the media, so you can't reinstall and configure it yourself) would cost a little less, but certainly nowhere near $50.
Office 2003 professional (again, OEM, not retail) costs $319.95. Yes, it's also a little cheaper from a big vendor but nowhere near $100.
Please show me where you can buy windows for $50 and office for $100.
Finally! 2-phase commits. Distributed transactions can't be far behind. Is work already being done on them?
THANKYOU THANKYOU THANKYOU PostgreSQL team!!!
(I feel like a little kid who just got a new toy as a present).
This is ridiculous. They just keep on with blatant copyright infringement like nothing happened. When will someone put a stop to that?
* java is nearly as fast as C++ according to all the benchmarks I've seen. Yes, really. The perception of java as being "slow" is simply the legacy of the old awt apps. Yes, the awt gui was (and is) slow. Server-side java applications are not. The "much better performance" is simply not there, particularly for typical enterprise apps.
* *All* the enterprise apps (which is the area where java is particularly successful) store stuff in a database and/or talk to remote apps. Newsflash: a database query or a remote procedure call is *orders of magnitude slower* than an in-process procedure call. Once you include DB/RPC into the equation, whatever little speed advantage C++ has is wiped out completely.
* This is CS 101: performance of a program is largely determined by the algorithm used. You can write a linear search in assembly, and it will be very fast for small lists. But for large lists, a binary search written in shell script will beat it.
* In an enterprise application scalability is much more important than raw speed. So what if I can write a C++ app that's 20% faster than an equivalent java app? Java has frameworks that make it easy to write an app that you can scale horizontally (i.e. by adding more boxes). Easy being the keyword.
* Developer's time is much more expensive than runtime. It is *much faster* to write an app in java than in C++. And for all but the smallest/simplest apps it is faster to write the app in java than in PHP/perl/whatever.
If it's a safety/security issue then again you could build the same thing in a native compiled language, sandbox and all.
Uhhhm, yes. Safety and security are *big* issues in enterprise apps. Show me *one* native language and platform that does it. You are saying it like one can just wave a magic wand and have it built in no time. "You could build the same thing" is not "it's already built".
I mean really, is it just because Java provides a lot of easy to use API's?
Yes. among all the other things I've mentioned.
These are just a few reasons why java is so popular in enterprise apps. Sure, I wouldn't write a game in java, but for enterprise apps, it's perfect. Why java and not PHP/perl/? Simply because java is better. It has all the advantages of compiled laguages (type safety, variable declaration checking, syntax checking, etc.) without some of the disadvantages (manual memory management). Think of java compiler as a sanity checker for your code. It will catch common mistakes like typos, missing return statements, invalid function parameters, etc. A scripting language will not complain about that, but force you to spend hours tracking down the bug. That's why java is faster to develop in than any scripting language for large apps.
Any word on when they are planning to fix this? With this careless disregard for data integrity, it's hard for me to take MySQL seriously.
Here is what would be a lot more useful:
- buy a 20GB iPod
- buy a 80GB 1.8" HD
- upgrade the HD in the iPod
This would be awesome if you fill up the HD but don't want to shell out $$$ for a whole new unit. Is this possible? I'd love to buy a 20GB model knowing that if I ever run out of space I can upgrade the HD.
"We've responded to a request for information from the European Commission... we were not proactive, they came to us."
Sounds like someone is already scared shitless of retaliation. "It wasn't me -- it was all him, I swear!"
At least they make decent furniture...
Translation: We can't take the code developed by thousands of programmers over 15 years, make it proprietary, and contribute nothing back.
Response: Yep. that's the whole fucking point!
In all this open source/closed source voting debate people completely miss the more important question: *why* are you pushing for voting machines in the first place? What problem are you trying to solve?
As a Canadian, I am completely baffled by our neighbours south of the border. Here in Canada, the *entire country* uses identical paper ballots and it works beautifully. Nothing can be more simple, transparent and verifiable than that.
Let me give you an example I really like. Back in 2000, Canadian federal election was called at the end of november, so it occured a few weeks after the US election. We knew the results the next morning (or, those who cared to stay up late, knew it the same day). In the meantime, our friends south of the border were still counting pregnent chads and butterfly ballots. At that point everyone went "huh? *that* is the world's greatest democracy?"
So seriously guys, what problem are you trying to solve with punch cards and computers? It clearly can't be the scale. Canada has twice the population of Florida and way more political parties. Convenience? No, can't be that either. One of the problems in Florida was that the voters found the butterfly ballots confusing. Speed of counting? No, can't be that. Canada, with twice the population and much greater voter turnout, managed to count all the ballots by hand in a few hours after the polls closed. So... uhhh.... what?
The way I see it, anything other than paper ballots serves only to obuscate voting and provide pork barrel for corporations that "donate" enough money. Electronic voting machines make the problem much worse. If there is no physical record of a vote, fraud and vote tampering is ridiculously easy. Think about it: how can you trust that a computer will add 1 vote to your candidate when you press the button? A group of security researchers have answered that question: you can't. Voting machines must contend with two conflicting requirements: verifiability and voter anonymity. Therefore, the only machine that provably satisfies both requirements is one that prints out a piece of paper that you deposit into the ballot box. In other words, a machine that acts as nothing more than a high-tech pencil. Whoop-deee-dooo! big progress!
So anyway, while open source voting machines are "better", they still don't solve the root of the problem: electronic voting reduces transparency and simplifies vote tampering. The proper solution solution is to go back to paper and pencil. But no, we can't have that. That would be admitting a mistake. And USians never make mistakes. Besides, paper & pencil is only used in those backwards uncivilized countries like Canada, Britain, Germany, France, Japan, etc. We are all k00l and high-tech and stuff!!!
and 30% cooler, with 200% more wiz-bang factor!
Have you bothered to RTFM?
I tried building it several times, and every single time it was broken.
never , tortured eh?
I have no clue what I'm doing, but I'm considering getting some apples. One of my buddies actually likes apples. I've never tried them but I like oranges. Are there any benefits of apples over oranges?
And how the fuck are you going to transfer *hundreds of gigabytes* of data required to render a frame over the internet? How are you going to receive the data back? (2MB - 12MB per layer per frame).
Does that thing even have Renderman installed? (at $5k/CPU I highly doubt it). Does it have Shake? Does it have Houdini? Does it have Maya?
Besides that, how the fuck are you going to get approval to send _anything_ out of the studio? You obviously have never worked in the industry.
I'm also skeptical as to whether there is any use for this. What sort of environment do they run it on? Solaris/SPARC? Solaris/x86? Linux? Windows? What sort of software does it have installed? Would it ever be possible to replicate the in-house environment on this "grid"? (you know, with all the custom software, directory structure, environment variables, aliases, etc.) I know for a fact that there is no way we could outsource our rendering to Sun even if we tried.
The whole "CPU-hour" thing is a very nebulous concept. Environments differ wildly from one company to another, so you can never have a universal "CPU grid" in the same sense as you can have an electric grid.
The whole point of HDCP is that there is *nothing* between the "protected" content and the output device that could be used to retrieve the decrypted signal. Your dongle could be connected to some sort of recorder instead of the monitor, making the end-to-end encryption useless.