Well, I've been bitten by a few date handling issues in the past.
Perhaps some are corrected. Is Feb. 31st still a valid date in MySQL? It seems to me that in order to maintain backwards compatibility, MySQL would have to continue to do some of the strage things it did before. And "strange" is certainly in the eye of the beholder, but some things just really didn't fit my brain well at all.
I have a similar attitude toward the developers of MySQL.
However, you should realize that with either, the probability of hardware failure is much greater than software failure (you might have a different story if you buy good hardware).
What worries me more than crashes of MySQL is the fear that it will do something I don't expect. Perhaps MySQL makes a lot of sense to some people, but PostgreSQL fits my brain much better.
When reporting benchmarks, you should report in excruciating detail. If it's too long for a post, give us a link to a website about the benchmark.
PostgreSQL and MySQL are designed to perform in different environments. There are fundamental design choices that determine the areas that each will excel. The most major one is PostgreSQL's MVCC vs. MySQL's locking. Each strategy is used to maintain ACID compliance (I'm talking about InnoDB now, since that has a more comparable feature set), but the performance implications are profound. In particular, PostgreSQL avoids many performance issues with locking. However, for a web app, maybe you don't care so much about locking. It all depends.
Each benchmark only matters to the specific set of database operations your applications are performing. Being more clear about the benchmarks enables the readers to either: (a) relate to your results because their applications perform similar operations; or (b) decide that a bunch of "select 1" queries from a single app aren't really representative of their usage patterns.
I am not saying that you ran a bunch of "select 1" queries. But without the tuning parameters of the benchmark software and the detailed sequence of events, your comment is no more useful.
Electing representatives or presidents is increasingly a choice between which rights you are more willing to concede.
It's almost as if the Democrats will protect the odd Amendments, and the Republicans will protect the even ones.
People sometimes don't understand that it's better to leave only essential functions to government. Government power is orders of magnitude more dangerous than civilian power.
For those who want to "protect" themselves from actions by a fellow citizen by granting additional powers to the government: consider the worst that the citizen can do to you, then consider the worst the government can do to you with those additional powers.
Well, the first rule of goal-setting is to set an achievable goal with a realistic plan for success.
Brazil cannot feed everyone in its country. Period. They aren't as bad as some countries, but they don't have the resources to sustain non-productive people. Sad but true. Now that we've come to this realization, we can talk sense about the best of two unfortunate choices.
Brazil could divert all the money in taxes to feeding people. But then there would be no police and the country would quickly descend into chaos. Then you have more hungry people.
A more achievable goal would be using tax money to improve infrastructure and encourage business growth. Some will go hungry today, but there is hope for future generations.
Great point. In fact this topic was just discussed again on the PostgreSQL mailing lists, and the importance of running the database unprivileged was emphasized.
Not only that, what is the benefit of running a DB as root/Admin? If it didn't need port 80, I bet people wouldn't run apache as root either.
It would be nice if application developers made their apps database agnostic, but it rarely seems to happen.
That might be fine if your application uses only the features supported by all databases.
If you want more, you end up with a huge mess of bug-prone client side database operations. To ensure consistency of the data you have to do a HUGE amount of client side work because some databases don't support check constraints or constraint triggers. And all the other features it's the same deal: a huge amount of client-side code to accomplish something already available in most databases.
So why would the application programmer spend all of their time maintaining all those database layers?
It works for some applications, but for others it can be an exercise in futility.
Although I am a postgresql advocate, I want to caution users that win32 is very different from UNIX. PostgreSQL doesn't have a long track record on win32, merely a lengthy beta test. So, it's a great database, but stop short of assuming that PostgreSQL's legendary reliability was translated perfectly to win32. After a few more months of real-world testing, you can be much more sure.
You give absolutely no evidence to your claim that the bird population in Africa would be in jeapordy. Also, it's not much consolation to the millions of people who die from malaria.
It would be nice if people actually stated the tradeoffs of all these environmental policies. I bet a lot more people would go along with the policies if they felt they could trust the environmentalists to weigh costs, but tragically nobody can.
I could easily turn your statement around and say that you are being self-righteous about birds at the cost of millions of people.
Or, you could tell those kids dying in Africa that they should be happy a robin doesn't lay eggs that are too fragile, because that's exactly what the tradeoff was when DDT was banned. DDT was effective at killing misquitos which carry malaria, but now, misquitos aren't being controlled and millions more people are dying as a result.
You're absolutely right, the situation is complex and there is no good answer.
Maybe we should get the federal government out of it and leave it up to the states.
After all, the Roe v. Wade decision was made by 9 people and effectively made law for the entire nation. I don't see any constitutional basis for denying the states the ability to legislate the issue. Perhaps some people feel as though abortion is a civil liberty, but it's not in the Constitution, so those people need an Amendment first.
Seriously, though. Infanticide is different than murder in some important ways. You don't walk down the streets at night afraid of being aborted. Since it's killing your own genetic material only (well, and the father's, which many people never mention), that means really you only have one person to be afraid of: your mother. And most people aren't afriad of their mother killing them.
Speaking of fathers, why aren't the fathers involved in the decision? An abortion is basically "I don't like the way this baby is going to affect my life, so I'll kill it" in most cases. So why can't the father have an equal say?
And don't bring in some corner case where the mother has to decide between her own life and her baby's life. That is a rare reason for an abortion. It's much more common to just get a doctor to say that than for it to actually be true.
Afilias employees are regulars around the PostgreSQL mailing lists (and important developers). The company also funds development of important features and related projects (notably Slony-I, a bsd licensed replication engine).
July 7-11, 2003: Afilias database expert Andrew Sullivan will present the session "Backing a 24/7 Registry with PostgreSQL" at the O'Reilly Open Source Software Convention 2003 at the Portland Marriott Downtown.
Thatindicates to me that Afilias conducts its primary operations with PostgreSQL.
I disagree. An developer's use of OOP is not an all-or-nothing proposition, and there's no reason it should be. Some ideas lend themselves to OOP, and another idea in the same application might lend itself toward procedural programming.
It's possible plJava will make it into the core, and possible that it won't.
There are many good reasons to leave it a project outside of core, and such a project should not be considered "lower quality".
The main benefits to it being outside of core have to do with the release. For instance, you might not want to wait a year between releases of pljava. Similarly you wouldn't want the release of PostgreSQL held up because pljava wants to sneak another patch in before the feature freeze.
That's true, and I agree, but the larger issue is this:
It's a feature. The selection of standard procedural languages is inadequate (or perhaps absent is a better word). But procedural languages happen to be useful, so PostgreSQL provides as many as it can (I think they even have plphp now...).
When there's no standard, that doesn't mean you do nothing. PostgreSQL is doing more than a lot of other systems! They have an extensible procedural language system allowing maximum flexibility. That way, when something does become a reasonable standard, they will be ahead of the pack.
I haven't used it yet, but whoever writes for the project is an excellent communicator.
I was initially interested in the project a while back, just because I thought it might have some simple uses. I was very turned off by the website actually.
They are trying to show how it's faster than MySQL or PostgreSQL (I'll ignore the fact that they use really old versions and haven't updated the site), and the "common operations" they show are completely rediculous.
They say that to acheive speed you have to put multiple operations in one transaction. Ok, fine, good advice for any database. But some operations don't belong in the same transaction. And 25k insert statements in one transaction is not exactly a "common operation" it's more like a data load of some kind (for which postgresql has long had an alternate mechanism called COPY).
For live application performance, the average TPS is what matters, because the application spec determines what is inside one transaction and what is inside the next.
The bechmark is the worst kind: completely contrived, and misleading to those that read it. And worse, the author misses an opportunity to educate the novice readers, and instead misinforms them.
Maybe SQLite is a good product. But trying to impress people by showing the speed of one big transaction makes no sense in the real world, even for small sites.
Slashdot Mirror
Thanks, that's interesting. I'll have to try out that ProxyPass thing.
Well, I've been bitten by a few date handling issues in the past.
Perhaps some are corrected. Is Feb. 31st still a valid date in MySQL? It seems to me that in order to maintain backwards compatibility, MySQL would have to continue to do some of the strage things it did before. And "strange" is certainly in the eye of the beholder, but some things just really didn't fit my brain well at all.
I think that has to do with the number of users also.
If someone asks for PostgreSQL by name, they just don't care about a few bucks a month, and they are interested in higher-quality hosting.
If PostgreSQL were ubiquitous, I'm sure the hosting would be just as cheap.
I have a similar attitude toward the developers of MySQL.
However, you should realize that with either, the probability of hardware failure is much greater than software failure (you might have a different story if you buy good hardware).
What worries me more than crashes of MySQL is the fear that it will do something I don't expect. Perhaps MySQL makes a lot of sense to some people, but PostgreSQL fits my brain much better.
When reporting benchmarks, you should report in excruciating detail. If it's too long for a post, give us a link to a website about the benchmark.
PostgreSQL and MySQL are designed to perform in different environments. There are fundamental design choices that determine the areas that each will excel. The most major one is PostgreSQL's MVCC vs. MySQL's locking. Each strategy is used to maintain ACID compliance (I'm talking about InnoDB now, since that has a more comparable feature set), but the performance implications are profound. In particular, PostgreSQL avoids many performance issues with locking. However, for a web app, maybe you don't care so much about locking. It all depends.
Each benchmark only matters to the specific set of database operations your applications are performing. Being more clear about the benchmarks enables the readers to either:
(a) relate to your results because their applications perform similar operations; or
(b) decide that a bunch of "select 1" queries from a single app aren't really representative of their usage patterns.
I am not saying that you ran a bunch of "select 1" queries. But without the tuning parameters of the benchmark software and the detailed sequence of events, your comment is no more useful.
Well said! My sentiments exactly.
Electing representatives or presidents is increasingly a choice between which rights you are more willing to concede.
It's almost as if the Democrats will protect the odd Amendments, and the Republicans will protect the even ones.
People sometimes don't understand that it's better to leave only essential functions to government. Government power is orders of magnitude more dangerous than civilian power.
For those who want to "protect" themselves from actions by a fellow citizen by granting additional powers to the government: consider the worst that the citizen can do to you, then consider the worst the government can do to you with those additional powers.
Well, the first rule of goal-setting is to set an achievable goal with a realistic plan for success.
Brazil cannot feed everyone in its country. Period. They aren't as bad as some countries, but they don't have the resources to sustain non-productive people. Sad but true. Now that we've come to this realization, we can talk sense about the best of two unfortunate choices.
Brazil could divert all the money in taxes to feeding people. But then there would be no police and the country would quickly descend into chaos. Then you have more hungry people.
A more achievable goal would be using tax money to improve infrastructure and encourage business growth. Some will go hungry today, but there is hope for future generations.
Those people aren't willfully releasing the virus.
Really, is it that hard to make the analogy to a real virus?
If you get sick and transmit the virus to someone, oh well.
If you cultivate a virus and intentionally spread it around, you should go to jail.
Great point. In fact this topic was just discussed again on the PostgreSQL mailing lists, and the importance of running the database unprivileged was emphasized.
Not only that, what is the benefit of running a DB as root/Admin? If it didn't need port 80, I bet people wouldn't run apache as root either.
It would be nice if application developers made their apps database agnostic, but it rarely seems to happen.
That might be fine if your application uses only the features supported by all databases.
If you want more, you end up with a huge mess of bug-prone client side database operations. To ensure consistency of the data you have to do a HUGE amount of client side work because some databases don't support check constraints or constraint triggers. And all the other features it's the same deal: a huge amount of client-side code to accomplish something already available in most databases.
So why would the application programmer spend all of their time maintaining all those database layers?
It works for some applications, but for others it can be an exercise in futility.
Although I am a postgresql advocate, I want to caution users that win32 is very different from UNIX. PostgreSQL doesn't have a long track record on win32, merely a lengthy beta test. So, it's a great database, but stop short of assuming that PostgreSQL's legendary reliability was translated perfectly to win32. After a few more months of real-world testing, you can be much more sure.
Robins eat misquitos? I had no idea...
You give absolutely no evidence to your claim that the bird population in Africa would be in jeapordy. Also, it's not much consolation to the millions of people who die from malaria.
It would be nice if people actually stated the tradeoffs of all these environmental policies. I bet a lot more people would go along with the policies if they felt they could trust the environmentalists to weigh costs, but tragically nobody can.
I could easily turn your statement around and say that you are being self-righteous about birds at the cost of millions of people.
Or, you could tell those kids dying in Africa that they should be happy a robin doesn't lay eggs that are too fragile, because that's exactly what the tradeoff was when DDT was banned. DDT was effective at killing misquitos which carry malaria, but now, misquitos aren't being controlled and millions more people are dying as a result.
You're absolutely right, the situation is complex and there is no good answer.
Maybe we should get the federal government out of it and leave it up to the states.
After all, the Roe v. Wade decision was made by 9 people and effectively made law for the entire nation. I don't see any constitutional basis for denying the states the ability to legislate the issue. Perhaps some people feel as though abortion is a civil liberty, but it's not in the Constitution, so those people need an Amendment first.
Is motherhood a medical condition?
Seriously, though. Infanticide is different than murder in some important ways. You don't walk down the streets at night afraid of being aborted. Since it's killing your own genetic material only (well, and the father's, which many people never mention), that means really you only have one person to be afraid of: your mother. And most people aren't afriad of their mother killing them.
Speaking of fathers, why aren't the fathers involved in the decision? An abortion is basically "I don't like the way this baby is going to affect my life, so I'll kill it" in most cases. So why can't the father have an equal say?
And don't bring in some corner case where the mother has to decide between her own life and her baby's life. That is a rare reason for an abortion. It's much more common to just get a doctor to say that than for it to actually be true.
From the Afilias Website:
Thatindicates to me that Afilias conducts its primary operations with PostgreSQL.
I disagree. An developer's use of OOP is not an all-or-nothing proposition, and there's no reason it should be. Some ideas lend themselves to OOP, and another idea in the same application might lend itself toward procedural programming.
Thanks.
What would you say is the primary reason to not put the full text search in an RDBMS?
It's possible plJava will make it into the core, and possible that it won't.
There are many good reasons to leave it a project outside of core, and such a project should not be considered "lower quality".
The main benefits to it being outside of core have to do with the release. For instance, you might not want to wait a year between releases of pljava. Similarly you wouldn't want the release of PostgreSQL held up because pljava wants to sneak another patch in before the feature freeze.
I think the largest company to support PostgreSQL would be Fujitsu.
There are many others I would like to list, but I don't want to leave anyone out.
But yes, I welcome Pervasive's new support, and hope to see many great new things.
plJava
That's true, and I agree, but the larger issue is this:
It's a feature. The selection of standard procedural languages is inadequate (or perhaps absent is a better word). But procedural languages happen to be useful, so PostgreSQL provides as many as it can (I think they even have plphp now...).
When there's no standard, that doesn't mean you do nothing. PostgreSQL is doing more than a lot of other systems! They have an extensible procedural language system allowing maximum flexibility. That way, when something does become a reasonable standard, they will be ahead of the pack.
I haven't used it yet, but whoever writes for the project is an excellent communicator.
I was initially interested in the project a while back, just because I thought it might have some simple uses. I was very turned off by the website actually.
They are trying to show how it's faster than MySQL or PostgreSQL (I'll ignore the fact that they use really old versions and haven't updated the site), and the "common operations" they show are completely rediculous.
They say that to acheive speed you have to put multiple operations in one transaction. Ok, fine, good advice for any database. But some operations don't belong in the same transaction. And 25k insert statements in one transaction is not exactly a "common operation" it's more like a data load of some kind (for which postgresql has long had an alternate mechanism called COPY).
For live application performance, the average TPS is what matters, because the application spec determines what is inside one transaction and what is inside the next.
The bechmark is the worst kind: completely contrived, and misleading to those that read it. And worse, the author misses an opportunity to educate the novice readers, and instead misinforms them.
Maybe SQLite is a good product. But trying to impress people by showing the speed of one big transaction makes no sense in the real world, even for small sites.
I haven't heard that before. Could you point me to some resources so I can learn more?
I'm not sure what that has to do with my comment, but I agree with both points you made.