From: Cédric Villemain <cedric@2ndquadrant.com>
To: pgsql-performance@postgresql.org
Cc: Craig James <cjames@emolecules.com>
Cc: Kevin Grittner <kgrittn@mail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Claudio Freire <klaussfreire@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: David Greco <David_Greco@harte-hanks.com>
Subject: Re: Hints (was Poor performance using CTE)
Date: Fri, 23 Nov 2012 11:05:52 +0100
Message-ID: <201211231105.56380.cedric@2ndquadrant.com> (raw)
In-Reply-To: <CAFwQ8reE2vLynnE9zO_i7WhmktbiKaSYbBrCvJXCQ62feqBGZQ@mail.gmail.com>
References: <20121121134232.68590@gmx.com>
<CAFwQ8reE2vLynnE9zO_i7WhmktbiKaSYbBrCvJXCQ62feqBGZQ@mail.gmail.com>
Le mercredi 21 novembre 2012 17:34:02, Craig James a écrit :
> On Wed, Nov 21, 2012 at 5:42 AM, Kevin Grittner <kgrittn@mail.com> wrote:
> > It's a tough problem. Disguising and not documenting the available
> > optimizer hints leads to more reports on where the optimizer should
> > be smarter, and has spurred optimizer improvements. ...
> > Regarding the above-mentioned benefits we would stand to lose by
> > having clear and documented hints, perhaps we could occasionally
> > solicit input on where people are finding hints useful to get ideas
> > on where we might want to improve the optimizer. As far as worrying
> > about people using hints to force a plan which is sub-optimal --
> > isn't that getting into nanny mode a bit too much?
>
> Toward that end, the hint documentation (which is almost always viewed as
> HTML) could be prefaced by a strong suggestion to post performance
> questions in this group first, with links to the "subscribe" page and the
> "how to report performance problems" FAQ. The hint documentation could even
> be minimalistic; suggest to developers that they should post their
> problematic queries here before resorting to hints. That would give the
> experts an opportunity to provide the normal advice. The correct hint
> syntax would be suggested only when all other avenues failed.
We have hooks in PostgreSQL. We already have at least one extension which is
using that to change the planner behavior.
We can have a bit more hooks and try to improve the cost estimate, this part
of the code is known to be built by reports and human estimations, also the
9.2 version got heavy modifications in this area.
Let the 'Hints' be inside an extension thus we are able to track them and fix
the planner/costestimate issues.
I don't see why PostgreSQL needs 'Hints' *in-core*.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Attachments:
signature.asc (application/pgp-signature, 489B) download
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: cedric@2ndquadrant.com, cjames@emolecules.com, kgrittn@mail.com, craig@2ndquadrant.com, tgl@sss.pgh.pa.us, klaussfreire@gmail.com, mmoncure@gmail.com, David_Greco@harte-hanks.com
Subject: Re: Hints (was Poor performance using CTE)
In-Reply-To: <201211231105.56380.cedric@2ndquadrant.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