Skip site navigation (1) Skip section navigation (2)

Re: spurious function execution in prepared statements.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>,pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: spurious function execution in prepared statements.
Date: 2004-09-30 15:02:01
Message-ID: 16697.1096556521@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> Here is the actual query:
> select lock_cuid(id), *
> ...
> 	order by wcl_vin_no, wcl_claim_no, id
> 	limit 1

Looks like Stephan made the right guess.

Logically the LIMIT executes after the ORDER BY, so the sorted result
has to be formed completely.  The fact that we are able to optimize
this in some cases does not represent a promise that we can do it in
all cases.  Ergo, it's not a bug.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Mark WongDate: 2004-09-30 16:33:34
Subject: Re: O_DIRECT setting
Previous:From: Merlin MoncureDate: 2004-09-30 14:58:34
Subject: Re: spurious function execution in prepared statements.

pgsql-hackers by date

Next:From: Jan WieckDate: 2004-09-30 15:50:48
Subject: Re: FlushRelationBuffers error
Previous:From: Merlin MoncureDate: 2004-09-30 14:58:34
Subject: Re: spurious function execution in prepared statements.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group