Re: Hints (was Poor performance using CTE)

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Kevin Grittner <kgrittn(at)mail(dot)com>
Cc: Craig Ringer <craig(at)2ndQuadrant(dot)com>, Craig James <cjames(at)emolecules(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, David Greco <David_Greco(at)harte-hanks(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hints (was Poor performance using CTE)
Date: 2012-11-21 16:05:17
Message-ID: 50ACFBBD.30204@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 21.11.2012 15:42, Kevin Grittner wrote:
> Better, IMV, would be to identify what sorts of hints people actually
> find useful, and use that as the basis for TODO items for optimizer
> improvement as well as inventing clear ways to specify the desired
> coercion. I liked the suggestion that a CTE which didn't need to be
> materialized because of side-effects or multiple references have a
> keyword. Personally, I think that AS MATERIALIZED x (SELECT ...)
> would be preferable to AS x (SELECT ... OFFSET 0) as the syntax to
> specify that.

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.

- Heikki

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Claudio Freire 2012-11-21 16:16:25 Re: Poor performance using CTE
Previous Message Heikki Linnakangas 2012-11-21 15:56:01 Re: Poor performance using CTE