I meant that I didn't know how it differs from the standard double-quote. Backtick seems to do the same thing as what the standard says a double-quote should do, so why don't they use the standard?
That's what seemed silly to me. I'd be interested to hear the reason for the use of backticks versus double-quote.
From my perspective, MySQL has two things over Postgres. MySQLAdministrator and they don't do silly things with case sensitivity.
Can you elaborate on the case sensitivity issue? As far as I can tell the only way PostgreSQL deviates from the standard is by folding to lower case rather than upper case because, well, lower case looks more readable.
MySQL, from what I can tell, has an entirely new backtick ("`") operator. I don't even really know what it does, but to me, that seems silly.
MySQL and Oracle compete like public transportation and the automotive industry[1]. They're different concepts used in very different ways, so they are not direct competitors like Ford and Chevy. However, one is still an alternative to the other, so they are indirect competitors.
In some ways indirect competition is more destructive because it's a positive feedback system. The auto industry takes off in the U.S., so we build lots of infrastructure that make cars more desirable, which means more cars are purchased. However, if one person purchases a Ford that doesn't reduce the desirability of a Chevy to someone else.
That extends to databases easily. For the sake of argument, let's say MySQL users tend to put more code in the applications, and less logic in the database than Oracle users. Then their application no longer has much need for Oracle, reducing the desirability of Oracle, leading to (perhaps) another application built upon the same database system.
[1] I am making a very loose analogy. If you're trying to figure out which database I'm calling public transportation, and why, you've already put more thought into this than I have.
There are many valid reasons to have a different storage engine that behaves the same way.
For instance, let's say PostgreSQL offered more than one storage engine. Possible new engines might be: (1) A table-stored-in-a-btree storage engine. The whole table would be stored in btree with the primary key as the btree key. Range queries would be much faster in some situations due to sequential access. Of course this method has serious costs and is not the best in most situations, but does have performance benefits in the right situation. (2) A storage engine that circumvents OS disk cache, perhaps by operating on a raw partition.
Both of those are of limited use, but are perfectly valid choices and available in other database systems. The important thing is that they don't change the bahvior at all, only performance.
The problem is *not* that the storage engines are modular. That's an innovative implementation decision, and it is not inherently bad.
What causes the problems for some people is the MySQL exposes a different behavior to the user for each storage engine. In other words, the storage engine is not abstracted away from the user, but just the opposite.
Examples include foreign key and transaction behavior on MyISAM tables (that is, the commands are ignored by a MyISAM table) versus the behavior on an InnoDB table (where the commands function as you might expect).
I think this could be the big push that they needed to seriously consider teaming up with the Postgres guys, which could be good news for everyone interested.
What is your plan for that, and what do you expect the result to be?
I understand exactly what the parent was saying. You seem to be saying that nobody wants hot coffee, with absolutely no evidence. My evidence that people did want hot coffee is that millions purchased it and went back for more. I'm not saying it's high-quality coffee, but it does meet many people's needs. And who are you to tell people that they don't want hot coffee if they do want hot coffee?
That comment was in response to someone who claimed that one could not drink McDonald's coffee without a trip to the hospital. His comment was simply untrue, and my response was a valid one.
Even if you wanted to, you still could not without a hospital trip.
Then how did so many millions of people drink the coffee and then be happy enough to go back and buy it again? To say that some hot coffee, which was still less than boiling, is as unsafe as drano is rediculous.
I notice that you totally ignored my very plausible reasons that people may have to want hotter coffee. Some people let their food cool down a little bit before eating it. That's just common sense. Some people add cream/milk, which could bring the temperature too low unless it started off "too hot". Some people just like the pleasure of smelling hot coffee/tea until it's cool enough to drink.
Remember that many things you cook at home use boiling water, which is hotter than the coffee you speak of. It's still common to serve the food immediately, at which point people might wait for it too cool by starting on another course of the meal.
And the very large sum of money that she was awarded initially totalled less than a day's coffee sales for McDonalds.
Totally irrelevent. Money is money, and it comes straight from the stockholders' pockets. Those stockholders are retirees and so forth; just regular people.
The thing I don't like about the McDonald's lawsiut is: what if some people like their coffee that hot? It's not totally unreasonable. Some people commute and may like the coffee to stay hot the entire time. Some people just like to sip it slowly. Some people still like it to be hot after they put stuff in the coffee (milk, cream, whatever). Or a combination of these factors.
Should it be illegal to sell coffee to meet the needs of those people? A few people avoid burns, millions of people suffer from lukewarm coffee. It's clearly called "hot coffee". I can't think of any warning that would be helpful beyond that. If it said "this coffee could cause 3rd degree burns, be careful" I don't think that would make any difference at all to the consumers' coffee habbits.
What's next? Sue a microwave manufacturer because "who would guess water could get that hot in just one minute?"? There are millions of products that you have to be careful with.
Perhaps I'm not understanding. Why do you need to return the space back to the filesystem if your database is going to grow again anyway?
Regular VACUUM will mark the space as free and reuse it, so it seems like the same net effect. I can't think of any situation in which a periodic VACUUM FULL is needed. Normally, after you VACUUM, the file sizes will remain constant (because it's just reusing the dead space) until the table is larger than it used to be (when it runs out of dead space to reuse).
But why do you even need to do a FULL? VACUUM doesn't release the space back to the filesystem, but it does mark it for reuse by PostgreSQL. That means you aren't wasting space, because the dead tuples from updates/deletes are reused the next time you update/insert.
VACUUM FULL is only if you need to return the space back to the filesystem. It physically moves tuples on disk, so it's very expensive.
Yeah, I think they are working on some of these things, but they are hard problems.
You can do hot binary block-level backups using PITR, but it won't work across versions of PostgreSQL. I think they want to make it work across versions, but it'll just take work.
The caching issues are probably not going to happen for a while. That is a lot more work, and it's less portable, and requires a long time of performance testing and so forth. DB2 will probably have it's place in your organization for a while.
It sounds like you know what you're doing, but I have to ask: are you sure you need to do a VACUUM FULL ANALYZE and do you understand the difference between that and just VACUUM ANALYZE? I can see why VACUUM FULL would kill your performace, it has to actually move tuples around on disk. A normal VACUUM just updates the free space map (FSM) and reuses the dead space.
I have a somewhat large table (~10M fairly wide rows, low updates). A VACCUM ANALYZE run takes a few minutes (I haven't measured in a while), but it doesn't seem unreasonable, and with the delay it doesn't kill other queries in the process.
But from a daily backup/restore perspective, a binary, block-level backup would win hands down.
Absolutely. PostgreSQL can do that with Point-In-Time Recovery, though unfortunately not between versions, which is a common situation. However, it would help you in your "botched warehouse" situation.
The more general problem that PostgreSQL needs to solve is that they need to be able to upgrade in-place disk structures rather than requiring dump/reload between minor versions.
With postgres, it relies VERY heavily on the OS to cache the data on the filesystem.
Very true. It makes me wonder how large the structures are for cache management are in a per-row caching system. Seems that you would have a smaller space for actual cached data, but a larger cache management structures. The cost for a cache miss would be the same though, since reading a block is about the same as reading a tuple from disk. Overall performance could only really be determined with numbers I suppose.
PostgreSQL is very extensible. There is currently no pl/csharp, but adding such a language is not an invasive change. There is a "CREATE LANGUAGE" command that lets you create the procedural language of your choice by supplying a C handler function.
Of cource, you need to be able to embed the interpreter. I think if you did, you'd get all the languages that are part of the CLR.
However, you could provide a little more constructive criticism. For instance, if a PostgreSQL developer read "[DB2] has its warts and bugs but it's 100 times more robust than PostgreSQL," what might he do to correct that problem? Does PostgreSQL crash? The statement is a too ambiguous. Are you saying that runtime configuration of memory settings and faster dump/restore are reasons that DB2 is more robust?
Slashdot Mirror
Isn't PostgreSQL just following the standard?
With PostgreSQL you can use languages like java and perl.
That's hardly vendor lock-in.
I meant that I didn't know how it differs from the standard double-quote. Backtick seems to do the same thing as what the standard says a double-quote should do, so why don't they use the standard?
That's what seemed silly to me. I'd be interested to hear the reason for the use of backticks versus double-quote.
From my perspective, MySQL has two things over Postgres. MySQLAdministrator and they don't do silly things with case sensitivity.
Can you elaborate on the case sensitivity issue? As far as I can tell the only way PostgreSQL deviates from the standard is by folding to lower case rather than upper case because, well, lower case looks more readable.
MySQL, from what I can tell, has an entirely new backtick ("`") operator. I don't even really know what it does, but to me, that seems silly.
MySQL and Oracle compete like public transportation and the automotive industry[1]. They're different concepts used in very different ways, so they are not direct competitors like Ford and Chevy. However, one is still an alternative to the other, so they are indirect competitors.
In some ways indirect competition is more destructive because it's a positive feedback system. The auto industry takes off in the U.S., so we build lots of infrastructure that make cars more desirable, which means more cars are purchased. However, if one person purchases a Ford that doesn't reduce the desirability of a Chevy to someone else.
That extends to databases easily. For the sake of argument, let's say MySQL users tend to put more code in the applications, and less logic in the database than Oracle users. Then their application no longer has much need for Oracle, reducing the desirability of Oracle, leading to (perhaps) another application built upon the same database system.
[1] I am making a very loose analogy. If you're trying to figure out which database I'm calling public transportation, and why, you've already put more thought into this than I have.
There are many valid reasons to have a different storage engine that behaves the same way.
For instance, let's say PostgreSQL offered more than one storage engine. Possible new engines might be:
(1) A table-stored-in-a-btree storage engine. The whole table would be stored in btree with the primary key as the btree key. Range queries would be much faster in some situations due to sequential access. Of course this method has serious costs and is not the best in most situations, but does have performance benefits in the right situation.
(2) A storage engine that circumvents OS disk cache, perhaps by operating on a raw partition.
Both of those are of limited use, but are perfectly valid choices and available in other database systems. The important thing is that they don't change the bahvior at all, only performance.
The problem is *not* that the storage engines are modular. That's an innovative implementation decision, and it is not inherently bad.
What causes the problems for some people is the MySQL exposes a different behavior to the user for each storage engine. In other words, the storage engine is not abstracted away from the user, but just the opposite.
Examples include foreign key and transaction behavior on MyISAM tables (that is, the commands are ignored by a MyISAM table) versus the behavior on an InnoDB table (where the commands function as you might expect).
I think this could be the big push that they needed to seriously consider teaming up with the Postgres guys, which could be good news for everyone interested.
What is your plan for that, and what do you expect the result to be?
I understand exactly what the parent was saying. You seem to be saying that nobody wants hot coffee, with absolutely no evidence. My evidence that people did want hot coffee is that millions purchased it and went back for more. I'm not saying it's high-quality coffee, but it does meet many people's needs. And who are you to tell people that they don't want hot coffee if they do want hot coffee?
That comment was in response to someone who claimed that one could not drink McDonald's coffee without a trip to the hospital. His comment was simply untrue, and my response was a valid one.
And didn't that Sony copy protection scheme violate a few copyrights itself?
Even if you wanted to, you still could not without a hospital trip.
Then how did so many millions of people drink the coffee and then be happy enough to go back and buy it again? To say that some hot coffee, which was still less than boiling, is as unsafe as drano is rediculous.
I notice that you totally ignored my very plausible reasons that people may have to want hotter coffee. Some people let their food cool down a little bit before eating it. That's just common sense. Some people add cream/milk, which could bring the temperature too low unless it started off "too hot". Some people just like the pleasure of smelling hot coffee/tea until it's cool enough to drink.
Remember that many things you cook at home use boiling water, which is hotter than the coffee you speak of. It's still common to serve the food immediately, at which point people might wait for it too cool by starting on another course of the meal.
And the very large sum of money that she was awarded initially totalled less than a day's coffee sales for McDonalds.
Totally irrelevent. Money is money, and it comes straight from the stockholders' pockets. Those stockholders are retirees and so forth; just regular people.
The thing I don't like about the McDonald's lawsiut is: what if some people like their coffee that hot? It's not totally unreasonable. Some people commute and may like the coffee to stay hot the entire time. Some people just like to sip it slowly. Some people still like it to be hot after they put stuff in the coffee (milk, cream, whatever). Or a combination of these factors.
Should it be illegal to sell coffee to meet the needs of those people? A few people avoid burns, millions of people suffer from lukewarm coffee. It's clearly called "hot coffee". I can't think of any warning that would be helpful beyond that. If it said "this coffee could cause 3rd degree burns, be careful" I don't think that would make any difference at all to the consumers' coffee habbits.
What's next? Sue a microwave manufacturer because "who would guess water could get that hot in just one minute?"? There are millions of products that you have to be careful with.
Perhaps I'm not understanding. Why do you need to return the space back to the filesystem if your database is going to grow again anyway?
Regular VACUUM will mark the space as free and reuse it, so it seems like the same net effect. I can't think of any situation in which a periodic VACUUM FULL is needed. Normally, after you VACUUM, the file sizes will remain constant (because it's just reusing the dead space) until the table is larger than it used to be (when it runs out of dead space to reuse).
But why do you even need to do a FULL? VACUUM doesn't release the space back to the filesystem, but it does mark it for reuse by PostgreSQL. That means you aren't wasting space, because the dead tuples from updates/deletes are reused the next time you update/insert.
VACUUM FULL is only if you need to return the space back to the filesystem. It physically moves tuples on disk, so it's very expensive.
Yeah, I think they are working on some of these things, but they are hard problems.
You can do hot binary block-level backups using PITR, but it won't work across versions of PostgreSQL. I think they want to make it work across versions, but it'll just take work.
The caching issues are probably not going to happen for a while. That is a lot more work, and it's less portable, and requires a long time of performance testing and so forth. DB2 will probably have it's place in your organization for a while.
It sounds like you know what you're doing, but I have to ask: are you sure you need to do a VACUUM FULL ANALYZE and do you understand the difference between that and just VACUUM ANALYZE? I can see why VACUUM FULL would kill your performace, it has to actually move tuples around on disk. A normal VACUUM just updates the free space map (FSM) and reuses the dead space.
I have a somewhat large table (~10M fairly wide rows, low updates). A VACCUM ANALYZE run takes a few minutes (I haven't measured in a while), but it doesn't seem unreasonable, and with the delay it doesn't kill other queries in the process.
But from a daily backup/restore perspective, a binary, block-level backup would win hands down.
Absolutely. PostgreSQL can do that with Point-In-Time Recovery, though unfortunately not between versions, which is a common situation. However, it would help you in your "botched warehouse" situation.
The more general problem that PostgreSQL needs to solve is that they need to be able to upgrade in-place disk structures rather than requiring dump/reload between minor versions.
With postgres, it relies VERY heavily on the OS to cache the data on the filesystem.
Very true. It makes me wonder how large the structures are for cache management are in a per-row caching system. Seems that you would have a smaller space for actual cached data, but a larger cache management structures. The cost for a cache miss would be the same though, since reading a block is about the same as reading a tuple from disk. Overall performance could only really be determined with numbers I suppose.
PostgreSQL is very extensible. There is currently no pl/csharp, but adding such a language is not an invasive change. There is a "CREATE LANGUAGE" command that lets you create the procedural language of your choice by supplying a C handler function.
Of cource, you need to be able to embed the interpreter. I think if you did, you'd get all the languages that are part of the CLR.
the connection costs kill you
If the connection time is significant, just use PgPool. It uses the PostgreSQL protocol itself, so you don't have to change your application at all.
Vacuums are a killer for us.
Have you tried the vacuum delay to prevent the VACUUM from slowing performance of concurrent queries?
Interesting comment.
However, you could provide a little more constructive criticism. For instance, if a PostgreSQL developer read "[DB2] has its warts and bugs but it's 100 times more robust than PostgreSQL," what might he do to correct that problem? Does PostgreSQL crash? The statement is a too ambiguous. Are you saying that runtime configuration of memory settings and faster dump/restore are reasons that DB2 is more robust?
Many settings require server restart, notably some of the memory settings.
Ok, now we're up to one fact. Can you please provide a source for the more overall natural resources part, which is what I originally asked for?
You didn't answer the question. I know what natural resources are, and I know that Canada is bigger than the U.S.