On 02/03/2011 10:38 AM, Mladen Gogala wrote:
With all due respect, I don't see how does the issue of hints fall into this category?
You have a few good arguments, and if you hadn't said this, it wouldn't have been so obvious that there was a fundamental philosophical disconnect. I asked this same question almost ten years ago, and the answer Tom gave me was more than sufficient.
It all boils down to the database. Hints, whether they're well-intentioned or not, effectively cover up bugs in the optimizer, planner, or some other approach the database is using to build its execution. Your analogy is that PG is a gas stove, so bundle a fire extinguisher. Well, the devs believe that the stove should be upgraded to electric or possibly even induction to remove the need for the extinguisher.
If they left hints in, it would just be one more thing to deprecate as the original need for the hint was removed. If you really need hints that badly, EnterpriseDB cobbled the Oracle syntax into the planner, and it seems to work alright. That doesn't mean it's right, just that it works. EnterpriseDB will now have to support those query hints forever, even if the planner gets so advanced they're effectively useless.
Well, those two databases are also used much more widely than Postgres, which means that they're doing something better than Postgres.
Please don't make arguments like this. "Better" is such a subjective evaluation it means nothing. Are Honda Accords "better" than Lamborghini Gallardos because more people buy Accords? The MySQL/PostgreSQL flame war is a long and sometimes bitter one, and bringing it up to try and persuade the devs to "see reason" is just going to backfire.
Hints are not even that complicated to program.
Then write a contrib module. It's not part of the core DB, and it probably never will be. This is a *very* old argument. There's literally nothing you can say, no argument you can bring, that hasn't been heard a million times in the last decade.
-- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@xxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
