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

Re: Scrollable cursors and Sort performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Scrollable cursors and Sort performance
Date: 2006-02-27 00:26:19
Message-ID: 4319.1140999979@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Fri, 2006-02-10 at 11:58 -0500, Tom Lane wrote:
>> I suspect that the right thing is not to see this as a planner issue at
>> all, but to try to drive the choice off the context in which the plan
>> gets invoked.  Possibly we could pass a "need random access" boolean
>> down through the ExecInitNode calls (I seem to recall some prior
>> discussion of doing something like that, in the context of telling
>> Materialize that it could be a no-op in some cases).

> Yeh, that was me just being a little vague on implementation, but
> handing off from planner to executor via the Plan node is what I was
> hacking at now. I'll follow your recommendation and do it for the
> general case. Propagating it down should allow a few similar
> optimizations. 

Have you done anything with this idea yet?  I was just thinking of
attacking it myself.  After looking at my old notes about Materialize,
I am thinking that we should add a "int flags" parameter to the InitNode
calls along with ExecutorStart and probably PortalStart.  This would
contain a bitwise OR of at least the following flag bits:

	need-ReScan
	need-backwards-scan
	need-mark-restore
	no-execute (so flags can replace ExecutorStart's explainOnly param)

We'd have lots of room for expansion, but these are the ones that seem
to have immediate use.  And most callers of ExecutorStart/PortalStart
know they don't need these things, so could just pass zero always.

Interesting point: how should EXPLAIN ANALYZE set these bits?  For its
own purposes it need not request random access, but it might be
interesting to make it possible to examine both the random and nonrandom
behaviors, now that these will be significantly different performancewise.
Possibly we could make EXPLAIN ANALYZE EXECUTE set the random-access
bits.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2006-02-27 04:04:09
Subject: Re: TOAST compression
Previous:From: Tom LaneDate: 2006-02-26 23:13:35
Subject: Re: possible design bug with PQescapeString()

pgsql-patches by date

Next:From: Qingqing ZhouDate: 2006-02-27 03:37:15
Subject: Re: <> operator
Previous:From: Neil ConwayDate: 2006-02-26 23:40:21
Subject: Re: 2 line patch to allow plpythonu functions to return

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