From: Shaun Thomas <sthomas@peak6.com>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: Thu, 3 Feb 2011 11:10:06 -0600
Message-ID: <4D4AE16E.9040807@peak6.com> (raw)
In-Reply-To: <4D4AD9F6.6040903@vmsinfo.com>
References: <201102012247.p11Ml6u02682@momjian.us>
<4D48914B.4050403@dunslane.net>
<4D489AD1.1010105@vmsinfo.com>
<AANLkTiknZi97dDwm7sHqy0EL7tpNEP9sY5uPV6AN+q=u@mail.gmail.com>
<4D499E55.4020107@vmsinfo.com>
<4D49A6B9.4060608@2ndquadrant.com>
<4D49C482.4010707@vmsinfo.com>
<4D49F0BA.9000901@2ndquadrant.com>
<4D4A16BF.1020304@vmsinfo.com>
<4D4A4844.3020409@2ndquadrant.com>
<4D4AD9F6.6040903@vmsinfo.com>
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@peak6.com
______________________________________________
See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sthomas@peak6.com
Subject: Re: [HACKERS] Slow count(*) again...
In-Reply-To: <4D4AE16E.9040807@peak6.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox