Sorry, that's no longer true. Remember a year ago when keyword searchs were lightening fast and all? Well, last summer sourceforge whored itself out to IBM and switched to DB2, and now it's dog slow.
Don't believe me? Grab a copy of sourceforge, download db2 personal edition and postgresql and compare for yourself. DB2 is a pig. A mighty, powerful, capable, but slow database. That's not just my opinion, it's the opinion of anyone who's benchmarked it against Postgresql lately.
FYI, the folks who are tuning the Linux 2.4/2.5 kernel for high performance under heavy parellel database load are switching FROM SAPdb to Postgresql because it is faster and can provide a greater load than SAPdb.
I'm willing to bet 99.9% of the folks saying Postgresql isn't as good as SAPdb haven't spent more than 5 minutes reading the glossy tri-folds for SAPdb or Postgresql.
Hah. Everybody knows that you put the old busted unit in without hooking up a data cable to it. Then you only have to remove your cup when turning it on. And put it above the working unit of course, since if you put it under it the working unit will spill your coffee. And then there's nothing to dunk your donut in.
We had a military radio made by Magnavox in the AF back in the day that had a steel / led case about 1/4" thick, made in slices with 4 long bolts holding them all together.
Those things were nearly indestructable. Pilots would step on them getting in and out. They would get dropped three or four feet. The air conditioning in some planes would dump a gallon of water in them when the evaporators went out. We'd just open it up, shake the water out, and sit it on top of a warm piece of test equipment to dry, and they'd always work. I always thought they must have been designed by somebody who was stuck in the real life "A Bridge Too Far" with shitty radios and wanted to make sure that the very last thing working on the plane was the radio when everything else had given out.
Re:And for the obligatory...
on
RAMdisk RAID?
·
· Score: 1
I've done a bit of testing on a server that has both IDE and SCSI drives in it AND is attached to a NAS.
The NAS wins, hands down, for random access stuff, and is aboutt as fast for linear stuff. the only thing it can't compete on is running postgresql, where having the disks local seems to be much faster. Plus I get nervous running a database across an NFS mount.
FYI, the SCSI drives offer linear read speeds of about 25 Megs a second each, the IDEs offer about 10Megs a second, and the NAS is connected via switched 100BaseTx FD, so it's only got 10 Megs a second to work with. I'm betting it's faster because of its internal caching and what not.
It has gig connections, we just can't justify the increased cost on an intranet server that already has sub second response time.
Novell already supports Postgresql on novell. Pity they can't be bothered to update their port though. It's stuck at 7.2.1, which has some bugs that really mean it should be updated to 7.2.3.
I define support as that which the original product creators will accept the bug fixes for. With GiST indexes, originally, they were an external feature, but are now incorporated.
If I show up on pgsql-hackers and ask for help with data cubes in efeu, they will refer me to the maintainer of efeu. If the efeu project gets to a point that they wanted the efeu code integrated into postgresql or delivered with it, then the guys on the hackers list would provide the support for that module.
But I agree that this is a great boon for pgsql and mysql in terms of exposure, and it really makes MS look like they don't care about their customers, just their margins.
But that is hardly the same thing. With the MSSQL server, it is a built in feature, while in Postgresql it's an addon. That's not the same as being supported by postgresql. Go on the hackers list and ask a question about data cubes and they'll tell you postgresql doesn't directly support them, but after market add ons do.
Therefore, postgresql itself stays unencumbered, which is the important point here. If timeline wants to go after folks, it would be the efeu people or the users of efeu.
By the way, the first listing on that page is the cygwin version of postgresql for windows, but the second section lists the beta of 7.2.1 which is the windows version that will be mostly used for the native windows version due out for version 7.4
Testing seems to show it being quite a bit faster than the cygwin version, and requiring signifigantly less skill to install and maintain as well.
You're quite wrong here. What they are talking about are data cubes, which mysql and pgsql don't support and are something quite different from a multi-domensional array, which both pgsql and mysql do support.
So, I refer you back to your own message for advice.
pg_dump not only runs WHILE the database is up, it does so in such a way as to ensure completely transactionally pure backups (i.e. snapshots) with virtually no impact on performance.
And they do so in SQL.
If you don't know anything about a subject you should keep you mouth shut. You only convince people you're ill informed and ignorant when you post lies.
The problem is it's hard to find a fair benchmark. Most SQL bencharks won't run on MySQL because it's missing so many features.
Postgresql can be tested by the OSDB suite found on source forge. It does well. But the most important benchmark is how well it runs YOUR query load. And no one other than you can benchmark that.
The real issue is how a database behaves under changing load conditions. How do both databases perform when you write once per second? What about 5 writes a second, 10 writes a second? Some database have serious contention issues between writes and reads.
Postgresql uses MVCC to reduce the contention to about zero on things like content management systems and what not. Which means it behaves well as write frequency increases. Try it and benchmark it for your load, it's the only way you can actually know.
Mind my asking what version you're running? And what kind of hardware? we do pretty well at work on a dual PIII-750 with 1.5gig ram (only about 512Meg used by postgresql, the rest is an app server.)
I'd say that when vacuum is run on this machine performance drops by about 2 to 5% at most. That's partial not full vacuums.
Absolutely. The thing is, if you have a contract that says you can truly screw over your database support provider, then they're actually less motivated to be straight forward with you. They'll hide problems from you hoping they don't come up instead of warning you ahead of time and taking care of them before they're trouble.
I have NEVER had to debate whether to upgrade within a major version (i.e. 7.2.0 to 7.2.1 to 7.2.2 and on) They have always worked, this is not Microsoft SQL, and I've upgraded EVERY single time there's been an update since 6.5.2 came out in 1999.
Postgresql is the LEAST of my worries as a sysadmin. I run backups and vacuums every night and the box has never gone down unscheduled in three years running postgresql. Yes, it is that good.
Basically, from what I've understood, they use Postgresql to maintain all the site admin / owner info and such, then push out from the database every x number of minutes to their dns servers the updates in a flat file or something like that.
So, Postgresql doesn't handle the load of DNS directly, it handles all the backend data maintenance and probably billing and such.
I'm not getting it. It's not like Postgresql is some tired old code somebody made a long time ago and nobody maintains or updates. The guys that make Postgresql work are pros and they're good at what they do.
The times between updates has been fairly short, and I have seen many people get patches from the hackers when somebody's SQL wasn't working right.
I started using Postgresql in 1999 at about version 6.5.1. The release schedule is:
Updates are fast and correct, and while the developers won't always do whatever a user wants, they are quite approachable, and genuinely nice folks.
I would say the support I get from the postgresql mailing lists is better than any support I've ever had before, period. And so would a lot of other postgresql users.
But you'll notice he said the database was "locking up". No matter how inefficient your query, or whatnot, you shouldn't be able to lock up a database with a select query. Period. And reducing the amount of data is never the answer.
I remember the horror story I lived through activating my RedHat 7.2 install last week. Must have taken hours on the phone with the folks at RedHat to get the license key to work.
The problem here is that genes normally don't transfer laterally among species, but the methodology of genetic engineering uses methods that encourage lateral transfer. The materials used to do this horizontal transfer in the lab don't all get dstroyed and can wind up in the wild.
If you haven't read "Mutant" by Peter Clement, do so. Genetic engineering is a nightmare waiting to happen. While "Mutant" is a fictional book, everything in it is quite possible, and I looked up everything in it at both the library in medical journals and online. Scary as hell, and the companies doing all the experimentation don't want you to know how dangerous it really is.
Slashdot Mirror
Sorry, that's no longer true. Remember a year ago when keyword searchs were lightening fast and all? Well, last summer sourceforge whored itself out to IBM and switched to DB2, and now it's dog slow.
Don't believe me? Grab a copy of sourceforge, download db2 personal edition and postgresql and compare for yourself. DB2 is a pig. A mighty, powerful, capable, but slow database. That's not just my opinion, it's the opinion of anyone who's benchmarked it against Postgresql lately.
FYI, the folks who are tuning the Linux 2.4/2.5 kernel for high performance under heavy parellel database load are switching FROM SAPdb to Postgresql because it is faster and can provide a greater load than SAPdb.
I'm willing to bet 99.9% of the folks saying Postgresql isn't as good as SAPdb haven't spent more than 5 minutes reading the glossy tri-folds for SAPdb or Postgresql.
Hah. Everybody knows that you put the old busted unit in without hooking up a data cable to it. Then you only have to remove your cup when turning it on. And put it above the working unit of course, since if you put it under it the working unit will spill your coffee. And then there's nothing to dunk your donut in.
We had a military radio made by Magnavox in the AF back in the day that had a steel / led case about 1/4" thick, made in slices with 4 long bolts holding them all together.
Those things were nearly indestructable. Pilots would step on them getting in and out. They would get dropped three or four feet. The air conditioning in some planes would dump a gallon of water in them when the evaporators went out. We'd just open it up, shake the water out, and sit it on top of a warm piece of test equipment to dry, and they'd always work. I always thought they must have been designed by somebody who was stuck in the real life "A Bridge Too Far" with shitty radios and wanted to make sure that the very last thing working on the plane was the radio when everything else had given out.
I've done a bit of testing on a server that has both IDE and SCSI drives in it AND is attached to a NAS.
The NAS wins, hands down, for random access stuff, and is aboutt as fast for linear stuff. the only thing it can't compete on is running postgresql, where having the disks local seems to be much faster. Plus I get nervous running a database across an NFS mount.
FYI, the SCSI drives offer linear read speeds of about 25 Megs a second each, the IDEs offer about 10Megs a second, and the NAS is connected via switched 100BaseTx FD, so it's only got 10 Megs a second to work with. I'm betting it's faster because of its internal caching and what not.
It has gig connections, we just can't justify the increased cost on an intranet server that already has sub second response time.
Novell already supports Postgresql on novell. Pity they can't be bothered to update their port though. It's stuck at 7.2.1, which has some bugs that really mean it should be updated to 7.2.3.
URL:
http://developer.novell.com/ndk/postgres.htm
I define support as that which the original product creators will accept the bug fixes for. With GiST indexes, originally, they were an external feature, but are now incorporated.
If I show up on pgsql-hackers and ask for help with data cubes in efeu, they will refer me to the maintainer of efeu. If the efeu project gets to a point that they wanted the efeu code integrated into postgresql or delivered with it, then the guys on the hackers list would provide the support for that module.
But I agree that this is a great boon for pgsql and mysql in terms of exposure, and it really makes MS look like they don't care about their customers, just their margins.
Well, I would classify MySQL as a 1980s toyota pickup, holds more than you think, and performs ok as long as you don't try to get too crazy.
I'd hardly qualify MSSQL as an 18 wheeler, unless you mean a 2 ton moving fan with another 12 wheels glued onto the side.
Oracle, Postgresql, Informix, DB2, these are 18 wheelers by comparison, but not MSSQL server. It firmly rests in the lower part of the food chain.
But that is hardly the same thing. With the MSSQL server, it is a built in feature, while in Postgresql it's an addon. That's not the same as being supported by postgresql. Go on the hackers list and ask a question about data cubes and they'll tell you postgresql doesn't directly support them, but after market add ons do.
Therefore, postgresql itself stays unencumbered, which is the important point here. If timeline wants to go after folks, it would be the efeu people or the users of efeu.
By the way, the first listing on that page is the cygwin version of postgresql for windows, but the second section lists the beta of 7.2.1 which is the windows version that will be mostly used for the native windows version due out for version 7.4
Testing seems to show it being quite a bit faster than the cygwin version, and requiring signifigantly less skill to install and maintain as well.
You're quite wrong here. What they are talking about are data cubes, which mysql and pgsql don't support and are something quite different from a multi-domensional array, which both pgsql and mysql do support.
So, I refer you back to your own message for advice.
http://techdocs.postgresql.org/guides/InstallingOn Windows
Oh, and it costs $1000 for a perpetual license to update a mysql database running on innodb hot.
That is a bold faced lie. You sir, are a liar.
pg_dump not only runs WHILE the database is up, it does so in such a way as to ensure completely transactionally pure backups (i.e. snapshots) with virtually no impact on performance.
And they do so in SQL.
If you don't know anything about a subject you should keep you mouth shut. You only convince people you're ill informed and ignorant when you post lies.
The problem is it's hard to find a fair benchmark. Most SQL bencharks won't run on MySQL because it's missing so many features.
Postgresql can be tested by the OSDB suite found on source forge. It does well. But the most important benchmark is how well it runs YOUR query load. And no one other than you can benchmark that.
The real issue is how a database behaves under changing load conditions. How do both databases perform when you write once per second? What about 5 writes a second, 10 writes a second? Some database have serious contention issues between writes and reads.
Postgresql uses MVCC to reduce the contention to about zero on things like content management systems and what not. Which means it behaves well as write frequency increases. Try it and benchmark it for your load, it's the only way you can actually know.
Mind my asking what version you're running? And what kind of hardware? we do pretty well at work on a dual PIII-750 with 1.5gig ram (only about 512Meg used by postgresql, the rest is an app server.)
I'd say that when vacuum is run on this machine performance drops by about 2 to 5% at most. That's partial not full vacuums.
Absolutely. The thing is, if you have a contract that says you can truly screw over your database support provider, then they're actually less motivated to be straight forward with you. They'll hide problems from you hoping they don't come up instead of warning you ahead of time and taking care of them before they're trouble.
I have NEVER had to debate whether to upgrade within a major version (i.e. 7.2.0 to 7.2.1 to 7.2.2 and on) They have always worked, this is not Microsoft SQL, and I've upgraded EVERY single time there's been an update since 6.5.2 came out in 1999.
Postgresql is the LEAST of my worries as a sysadmin. I run backups and vacuums every night and the box has never gone down unscheduled in three years running postgresql. Yes, it is that good.
Basically, from what I've understood, they use Postgresql to maintain all the site admin / owner info and such, then push out from the database every x number of minutes to their dns servers the updates in a flat file or something like that.
So, Postgresql doesn't handle the load of DNS directly, it handles all the backend data maintenance and probably billing and such.
That's funny. someone please mod it up.
I'm not getting it. It's not like Postgresql is some tired old code somebody made a long time ago and nobody maintains or updates. The guys that make Postgresql work are pros and they're good at what they do.
:
The times between updates has been fairly short, and I have seen many people get patches from the hackers when somebody's SQL wasn't working right.
I started using Postgresql in 1999 at about version 6.5.1. The release schedule is
version | release_date | time_to_next
6.5.0 | 1999-06-09 | 36
6.5.1 | 1999-07-15 | 62
6.5.2 | 1999-09-15 | 28
6.5.3 | 1999-10-13 | 208
7.0.0 | 2000-05-08 | 24
7.0.1 | 2000-06-01 | 4
7.0.2 | 2000-06-05 | 159
7.0.3 | 2000-11-11 | 143
7.1.0 | 2001-04-03 | 32
7.1.1 | 2001-05-05 | 6
7.1.2 | 2001-05-11 | 96
7.1.3 | 2001-08-15 | 173
7.2.0 | 2002-02-04 | 45
7.2.1 | 2002-03-21 | 155
7.2.2 | 2002-08-23 | 39
7.2.3 | 2002-10-01 | 57
7.3.0 | 2002-11-27 | 25
7.3.1 | 2002-12-22 |
Updates are fast and correct, and while the developers won't always do whatever a user wants, they are quite approachable, and genuinely nice folks.
I would say the support I get from the postgresql mailing lists is better than any support I've ever had before, period. And so would a lot of other postgresql users.
PS I HATE THE F**KING LAMNESS FILTER.
But you'll notice he said the database was "locking up". No matter how inefficient your query, or whatnot, you shouldn't be able to lock up a database with a select query. Period. And reducing the amount of data is never the answer.
I remember the horror story I lived through activating my RedHat 7.2 install last week. Must have taken hours on the phone with the folks at RedHat to get the license key to work.
Oh wait, that was Crystal Reports, never mind...
Hell, that sounds like a great reason to just finish the switch over to open source OS and office apps before your next maintenance payment is due.
And be sure and let your sales rep know WHY you are changing that last bit of Microsoft software out for something else.
I've been thinking of upgrading from my tape drive to the disk drive. It's either that or spring for a 16k ram cart...
The problem here is that genes normally don't transfer laterally among species, but the methodology of genetic engineering uses methods that encourage lateral transfer. The materials used to do this horizontal transfer in the lab don't all get dstroyed and can wind up in the wild.
If you haven't read "Mutant" by Peter Clement, do so. Genetic engineering is a nightmare waiting to happen. While "Mutant" is a fictional book, everything in it is quite possible, and I looked up everything in it at both the library in medical journals and online. Scary as hell, and the companies doing all the experimentation don't want you to know how dangerous it really is.