From: | Craig Ringer <craig(at)2ndQuadrant(dot)com> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com> |
Cc: | 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" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Hints (was Poor performance using CTE) |
Date: | 2012-11-21 02:15:17 |
Message-ID: | 50AC3935.6060508@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 11/21/2012 09:35 AM, Craig James wrote:
> Why not make an explicit hint syntax and document it? I've still don't
> understand why "hint" is a dirty word in Postgres. There are a
> half-dozen or so ways in common use to circumvent or correct
> sub-optimal plans.
>
The reason usually given is that hints provide easy workarounds for
planner and stats issues, so people don't report problems or fix the
underlying problem.
Of course, if that's all there was to it, `OFFSET 0` would be made into
an error or warning, or ignored and not fenced.
The reality is, as you say, that there's a need, because the planner can
never be perfect - or rather, if it were nearly perfect, it'd take so
long to read the stats and calculate plans that everything would be
glacially slow anyway. The planner has to compromise, and so cases will
always arise where it needs a little help.
I think it's time to admit that and get the syntax in place for CTEs so
there's room to optimize them later, rather than cementing
CTEs-as-fences in forever as a Pg quirk.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-11-21 13:04:38 | Re: Poor performance using CTE |
Previous Message | Craig James | 2012-11-21 01:35:38 | Hints (was Poor performance using CTE) |