Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Love <joe(at)primoweb(dot)com>
Cc: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement)
Date: 2013-11-05 18:25:58
Message-ID: 23267.1383675958@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Love <joe(at)primoweb(dot)com> writes:
> I'm wondering what type of index would work for this as it is a volatile
> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
> wouldn't be possible or worth doing. It seems to me that all functions in
> the "select" part of the statement could be calculated at the end of the
> query after the results have been gathered, and even after the sorting had
> been done as long as the column wasn't part of the order by (or perhaps
> group by).

The short answer is that doing so directly contradicts the computational
model defined by the SQL standard, and will break applications that rely
on the current behavior. Since there's already a clear way to write the
query in a way that specifies evaluating the functions after the
sort/limit steps (ie, put the order by/limit in a sub-select), IMHO that's
what you should do, not lobby to make the optimizer reinterpret what you
wrote.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-11-05 18:32:16 Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement)
Previous Message Tom Lane 2013-11-05 18:13:10 Better error message for window-function spec bizarreness