Actually, about 98% of all the traffic to the root level servers are bad requests that come from misconfigured windows boxen, so they are under continuous DDOS attack by accident to begin with. When the big DDOS attack went down a year or so ago, all that happened was that the 98% bad requests jumped to about 99%. Only one of the servers had a problem, and it was the oldest, slowest one there is. Since all the bad requests get rerouted to a single server that's just programmed to respond "bad request" the "DDOS" attack was basically only a slight increase in load on the routers, and that's about i.
Oh please, you just crank up fsm, run the autovacuum daemon and you're gold. a single fsm entry takes only 6 bytes of shared memory, even on a P120 with 64 Megs of ram you can afford several tens of thousands of slots.
Sorry, but I take offense at this attack on our community. I've gotten the fastest, best responses from the Postgresql mailing lists of any product, free or commercial, I've ever used.
Tom Lane, Peter Eisentraut, Bruce Momjian, Josh Berkus, and many others have been instrumental in answering hard questions, and they do so in a polite, if terse manner.
The documentation is great, if you already understand basic database theory. Agreed, there's not a lot of hand holding like how to make your first left join pretty, but there's lots of good documentation, and it is always getting better.
If you don't like the documentation, either contribute something to make it better, make a suggestion on how others can make it better, or stfu.
Me neither, but having to have it is one. I.e. PostgreSQL can only really run the main code base under cygwin, and while it runs reliably, the performance is mediocre at best. That's ok, cygwin is doing its job, allowing PostgreSQL to run on Windows reliably, albeit slowly.
But relying on it IS a wart for PostgreSQL, and it's being addressed.
That was all I meant. I love cygwin, what it lets me do (introduce windows users to F/OS software environments et. al.) but it's never gonna give the kind of performance that a native windows app will have.
Actually, Postgresql uses those pesky ANSI standard type names, while MySQL, as per usual, creates their own and perverts others (i.e. timestamp is an ansi spec type, but in mysql it means a datetime type that autoupdates to now() when updated / inserted.)
Also, there's a page delay patch being tested for 7.5 that will slow down vacuum quite a bit, thus letting other processes get priority access over it. It almost made it into 7.4 but arrived just a little too late.
Oh wait, MySQL doesn't have any of those features.
It's hard to benchmark two databases that are so very different, since we can either restrict the test to only things that both have in common, leaving out a huge number of features PostgreSQL has that MySQL doesn't, or we can try to write a benchmark that lets PostgreSQL use its features while MySQL tries to catch up in Perl/PHP code on the outside of the database.
Either way, one side is gonna call it an unfair test.
There are some nice benchmarks, but I don't think they'll run on MySQL:
We use it where I work, more as a batch file processor for our reports and such.
There are few things that make it more suitable now than ever before, one being hash aggregate method which gives MUCH faster output when doing aggregates on large sets. Another is pl/R, the R language as a stored procedure language.. The new GiST indexes also help, and there's a new and improved full text search engine in 7.4 as well.
We've found it to handle load MUCH better than MSSQL server (our uptimes on the server and postgresql both are measured in months (currently 245 or so days)). It's close to Oracle in performance, but for really big ugly queries, Oracle is still a bit more refined in the planner department.
Not exactly. If you try to enter a date of 'grandmas panties' as a date, postgresql will NOT accept it. MySQL will turn it into 0000-00-00.
If you try to insert 8123928392382923 into an int4 in postgresql, it will throw an error. MySQL will turn it into 2^31 (or 32 if it's unsigned).
If you make a not null column in postgresql, it will NOT ACCEPT A NULL, while MySQL will silently convert it to an acceptable default.
MySQL will allow you to define foreign key references to tables that can't support them, and silently fail to create or maintain them.
That's the problem, the silent failures / data munging. If there was a switch that I could throw that would let MySQL run ONLY on innodb tables and ONLY work the right way I might be tempted to use it, but their "what, me worry?" attitude towards data is a bit disheartening.
Not true, if your fsm settings are high enough and you vacuum regularly you NEVER need to vacuum full anymore, not even to prevent transaction id wrap around.
Errm, have you seen what's involved in actually _using_ this replication system?
Yes I have, and it's not all that hard to set up. Not a simple drool and click interface, but no harder than setting up the ftsearch or a few other projects I've put online
And actually, I'd rather have the database decide what gets cached and what doesn't.
Really? Even if it makes the wrong decision? What if the decisions it made would be exactly the same, is it still worth the 100s of man hours to create such a cache manager and maintain it?
You present no metrics for WHY the database should decide what stay in cache, yet you assume it would make a better decision. There are tons of things still to be done in Postgresql, (like the win32 port, Point in time recovery, 2 phase commit, and replication) to piss away time on a project of dubious returns like this.
This is misinformation. From my understanding, MySQL uses a single cygwin lib which is freely redistributable to provide for CLI paging functionality. That is all.
And if you check slashcode, you'll see that every single page that comes up is pretty much static and pre-packaged because of problems with MySQL handling load. And don't get me started with the HUGE delay when an article is being published, the whole site has been known to go catatonic for minutes at a time when that's going on.
Slashdot may run on MySQL, but that doesn't mean MySQL scales well, it means slashdot was originally written for MySQL, and it's not so easy to move off of it as much as it means anything.
Postgresql is generally a bit more work setting up, but a better choice for a system that needs to handly higher parallel transactional load, i.e. a real time shared system.
Can you imagine being 98% of the way through an http install of your favorite linux distro when this thing does this?
Or what about the windows user visiting windowsupdate who THINKS that they've gotten the latest and greatest patches, but is missing one because of this router?
Either situation would tend to really piss me off.
If I redistribute GPL software, my only requirements are to provide source code to the people I distribute the binaries to. I can charge anything I want. $1,000,000 if I want to.
BUT, the GPL guarantees the people I charged $1,000,000 for the binaries and source can then give the code away for free.
That's likely where SCO's gonna fall in the river.
Nope, didn't see it. Of course, I'm running Mozilla with popup blocking turned on. So I never see those things. Fitting that Mozilla saved me from a MS advert, huh?
Slashdot Mirror
Actually, about 98% of all the traffic to the root level servers are bad requests that come from misconfigured windows boxen, so they are under continuous DDOS attack by accident to begin with. When the big DDOS attack went down a year or so ago, all that happened was that the 98% bad requests jumped to about 99%. Only one of the servers had a problem, and it was the oldest, slowest one there is. Since all the bad requests get rerouted to a single server that's just programmed to respond "bad request" the "DDOS" attack was basically only a slight increase in load on the routers, and that's about i.
Has anyone used their new piece of equipment, the vt3? Their flyer / toaster combo certainly was impressive.
I'm guessing they're using the same proprietary fractal wavelet compression that provided such beautiful video back in the day.
Oh please, you just crank up fsm, run the autovacuum daemon and you're gold. a single fsm entry takes only 6 bytes of shared memory, even on a P120 with 64 Megs of ram you can afford several tens of thousands of slots.
Sorry, but I take offense at this attack on our community. I've gotten the fastest, best responses from the Postgresql mailing lists of any product, free or commercial, I've ever used.
Tom Lane, Peter Eisentraut, Bruce Momjian, Josh Berkus, and many others have been instrumental in answering hard questions, and they do so in a polite, if terse manner.
The documentation is great, if you already understand basic database theory. Agreed, there's not a lot of hand holding like how to make your first left join pretty, but there's lots of good documentation, and it is always getting better.
If you don't like the documentation, either contribute something to make it better, make a suggestion on how others can make it better, or stfu.
Me neither, but having to have it is one. I.e. PostgreSQL can only really run the main code base under cygwin, and while it runs reliably, the performance is mediocre at best. That's ok, cygwin is doing its job, allowing PostgreSQL to run on Windows reliably, albeit slowly.
But relying on it IS a wart for PostgreSQL, and it's being addressed.
That was all I meant. I love cygwin, what it lets me do (introduce windows users to F/OS software environments et. al.) but it's never gonna give the kind of performance that a native windows app will have.
Actually, Postgresql uses those pesky ANSI standard type names, while MySQL, as per usual, creates their own and perverts others (i.e. timestamp is an ansi spec type, but in mysql it means a datetime type that autoupdates to now() when updated / inserted.)
Also, there's a page delay patch being tested for 7.5 that will slow down vacuum quite a bit, thus letting other processes get priority access over it. It almost made it into 7.4 but arrived just a little too late.
It was surprisingly easy to build, install and activate. Works like a charm for us.
OK, here's a nice set of features we could benchmark:
triggers
views
check constraints
stored procedures
partial indexes
functional indexes
Oh wait, MySQL doesn't have any of those features.
It's hard to benchmark two databases that are so very different, since we can either restrict the test to only things that both have in common, leaving out a huge number of features PostgreSQL has that MySQL doesn't, or we can try to write a benchmark that lets PostgreSQL use its features while MySQL tries to catch up in Perl/PHP code on the outside of the database.
Either way, one side is gonna call it an unfair test.
There are some nice benchmarks, but I don't think they'll run on MySQL:
http://sourceforge.net/projects/osdldbt/
Yes, and if you remove that one dll, horror of horrors, you lose the ability to have CLI history in the mysql client. It's hardly the same.
Keep in mind, I'm a huge fan of Postgresql, and think MySQL has plenty of real warts to worry about without making any up.
We use it where I work, more as a batch file processor for our reports and such.
There are few things that make it more suitable now than ever before, one being hash aggregate method which gives MUCH faster output when doing aggregates on large sets. Another is pl/R, the R language as a stored procedure language.. The new GiST indexes also help, and there's a new and improved full text search engine in 7.4 as well.
We've found it to handle load MUCH better than MSSQL server (our uptimes on the server and postgresql both are measured in months (currently 245 or so days)). It's close to Oracle in performance, but for really big ugly queries, Oracle is still a bit more refined in the planner department.
Nope, 7.4 doesn't have native Winders support. However, it's about 75% done right now, and should be in 7.5 next spring.
Not exactly. If you try to enter a date of 'grandmas panties' as a date, postgresql will NOT accept it. MySQL will turn it into 0000-00-00.
If you try to insert 8123928392382923 into an int4 in postgresql, it will throw an error. MySQL will turn it into 2^31 (or 32 if it's unsigned).
If you make a not null column in postgresql, it will NOT ACCEPT A NULL, while MySQL will silently convert it to an acceptable default.
MySQL will allow you to define foreign key references to tables that can't support them, and silently fail to create or maintain them.
That's the problem, the silent failures / data munging. If there was a switch that I could throw that would let MySQL run ONLY on innodb tables and ONLY work the right way I might be tempted to use it, but their "what, me worry?" attitude towards data is a bit disheartening.
Not true, if your fsm settings are high enough and you vacuum regularly you NEVER need to vacuum full anymore, not even to prevent transaction id wrap around.
There's also an autovacuum daemon now, and it works quite well.
Errm, have you seen what's involved in actually _using_ this replication system?
Yes I have, and it's not all that hard to set up. Not a simple drool and click interface, but no harder than setting up the ftsearch or a few other projects I've put online
And actually, I'd rather have the database decide what gets cached and what doesn't.
Really? Even if it makes the wrong decision? What if the decisions it made would be exactly the same, is it still worth the 100s of man hours to create such a cache manager and maintain it?
You present no metrics for WHY the database should decide what stay in cache, yet you assume it would make a better decision. There are tons of things still to be done in Postgresql, (like the win32 port, Point in time recovery, 2 phase commit, and replication) to piss away time on a project of dubious returns like this.
Sure, but if you want a consistent hot backup, then you do have to pay for a commercial program.
If not, then you either take down the database, or get inconsistent backups.
This is misinformation. From my understanding, MySQL uses a single cygwin lib which is freely redistributable to provide for CLI paging functionality. That is all.
FYI, Postgresql does support prepared queries.
And if you check slashcode, you'll see that every single page that comes up is pretty much static and pre-packaged because of problems with MySQL handling load. And don't get me started with the HUGE delay when an article is being published, the whole site has been known to go catatonic for minutes at a time when that's going on.
Slashdot may run on MySQL, but that doesn't mean MySQL scales well, it means slashdot was originally written for MySQL, and it's not so easy to move off of it as much as it means anything.
If you try it again, try either phppgadmin or pgadminIII, they both are quite nice.
p gadmin.org/pgadmin3/index.php
http://phppgadmin.sourceforge.net/
http://www.
Postgresql is generally a bit more work setting up, but a better choice for a system that needs to handly higher parallel transactional load, i.e. a real time shared system.
Can you imagine being 98% of the way through an http install of your favorite linux distro when this thing does this?
Or what about the windows user visiting windowsupdate who THINKS that they've gotten the latest and greatest patches, but is missing one because of this router?
Either situation would tend to really piss me off.
If I redistribute GPL software, my only requirements are to provide source code to the people I distribute the binaries to. I can charge anything I want. $1,000,000 if I want to.
BUT, the GPL guarantees the people I charged $1,000,000 for the binaries and source can then give the code away for free.
That's likely where SCO's gonna fall in the river.
Let's all give Master Klon a great big hand!
Nope, didn't see it. Of course, I'm running Mozilla with popup blocking turned on. So I never see those things. Fitting that Mozilla saved me from a MS advert, huh?