From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, Joe Love <joe(at)primoweb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement) |
Date: | 2013-11-02 15:06:07 |
Message-ID: | 9466.1383404767@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
> I understand the reasons for executing SELECT before the sort. But,
> couldnt we get the planner to see the LIMIT part and push the sort
> node above the select node for this specific case?
[ Shrug... ] I don't see the point. If the OP actually cares about the
speed of this query, he's going to want to avoid the sort step too,
which is what makes the index a good idea.
More generally, this is not a transformation we could apply
unconditionally --- at the very least it'd need to be avoided when
volatile functions are involved, and I don't think it's invariably
a win from a cost standpoint even if there aren't semantic blockers.
But right now the planner has no real ability to reason about placement
of SELECT-list evaluation: it's done in a fixed spot in any particular
plan structure. I don't think it's practical to add such considerations
to the rat's nest that is grouping_planner and friends. I have
ambitions to replace all that with a Path-generation-and-comparison
approach, and the Paths used for this would need to carry some
indication of which expressions would be evaluated where. So maybe
once that's done we could think about whether this is worth doing.
I remain dubious though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-02 15:18:31 | Re: Record comparison compiler warning |
Previous Message | Alvaro Herrera | 2013-11-02 14:46:15 | Re: Record comparison compiler warning |