Re: Hints (was Poor performance using CTE) - Mailing list pgsql-performance

From Andreas Kretschmer
Subject Re: Hints (was Poor performance using CTE)
Date
Msg-id 20121121174808.GA29567@tux
Whole thread Raw
In response to Re: Hints (was Poor performance using CTE)  (Craig James <cjames@emolecules.com>)
List pgsql-performance
Craig James <cjames@emolecules.com> wrote:

>     On 11/21/2012 08:05 AM, Heikki Linnakangas wrote:
>     > Rather than telling the planner what to do or not to do, I'd much rather
>     > have hints that give the planner more information about the tables and
>     > quals involved in the query. A typical source of bad plans is when the
>     > planner gets its cost estimates wrong. So rather than telling the
>     > planner to use a nested loop join for "a INNER JOIN b ON a.id = b.id",
>     > the user could tell the planner that there are only 10 rows that match
>     > the "a.id = b.id" qual. That gives the planner the information it needs
>     > to choose the right plan on its own. That kind of hints would be much
>     > less implementation specific and much more likely to still be useful, or
>     > at least not outright counter-productive, in a future version with a
>     > smarter planner.
>     >
>     > You could also attach that kind of hints to tables and columns, which
>     > would be more portable and nicer than decorating all queries.
>
>     I like this idea, but also think that if we have a syntax to allow
>     hints, it would be nice to have a simple way to ignore all hints (yes, I
>     suppose I'm suggesting yet another GUC). That way after sprinkling your
>     SQL with hints, you could easily periodically (e.g. after a Postgres
>     upgrade) test what would happen if the hints were removed.
>
>
> Or a three-way choice: Allow, ignore, or generate an error.  That would allow
> developers to identify where hints are being used.
>
> Craig

+1

I think, we HAVE a smart planner, but hints in this direction are okay,
and we need a simple way to make such hints obsolete - for/in the future.


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.                              (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.              N 51.05082°, E 13.56889°


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hints (was Poor performance using CTE)
Next
From: Willem Leenen
Date:
Subject: Re: Hints - experiences from other rdbms