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: Jim Nasby <jim(at)nasby(dot)net>
Cc: Joe Love <joe(at)primoweb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement)
Date: 2013-11-01 20:30:19
Message-ID: 25400.1383337819@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <jim(at)nasby(dot)net> writes:
> On Oct 31, 2013, at 11:04 AM, Joe Love <joe(at)primoweb(dot)com> wrote:
>> In postgres 9.2 I have a function that is relatively expensive. When I write a query such as:
>>
>> select expensive_function(o.id),o.* from offeirng o where valid='Y' order by name limit 1;

> Does anyone know what the SQL standard says about this, if anything?

The computational model is that you evaluate the SELECT list before
sorting; this must be so since you can write

select somefunc(x) as y from tab order by y;

In the general case, therefore, it's impossible to avoid evaluating the
function at all rows. I'm not sure what the spec says about whether it's
okay to skip evaluation of functions that would be evaluated in a naive
implementation of the computational model, so it's possible that what
the OP is asking for is directly contrary to spec. But more likely they
permit implementations to skip "unnecessary" calls, if indeed they address
this at all.

As far as PG goes, I think the "excess" calls would only occur if the plan
includes an explicit sort step, since the select list would be evaluated
before the sort step. If you've got an index on "name" (or maybe you'd
need (valid, name) if there aren't many rows with valid = 'Y') I'd expect
it to pick out the minimal "name" row with the index, avoiding any sort,
and then the function would only be evaluated on the single fetched row.
But these are implementation details not anything you're going to find
support for in the spec.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-11-01 22:43:26 Re: Feature request: Optimizer improvement
Previous Message Jim Nasby 2013-11-01 20:24:29 Re: Feature request: Optimizer improvement