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

Re: Scrollable cursors and Sort performance

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Scrollable cursors and Sort performance
Date: 2006-02-27 14:17:23
Message-ID: 1141049843.2871.163.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
> 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.  

Started, but have been side-tracked by other urgent matters.

Happy to complete this today with you? This mini-project has made me
realise I don't understand the executor as well as I should, so I'm keen
to see it through, even if I'm a bit slower at it.

> 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.

Design-wise I was looking at putting a named struc in there, so it would
be easily expandible in the future to carry anything else that needs to
be passed down through the nodes like this. I guess thats the same
line-of-thought you're on too.

> 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.

Good point. Whichever we do will be wrong in some cases.... I've no real
opinion on this other than a vague preference for it to be quick.

Best Regards, Simon Riggs

In response to


pgsql-hackers by date

Next:From: Mark WoodwardDate: 2006-02-27 14:39:59
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Previous:From: Javier SomozaDate: 2006-02-27 12:29:19
Subject: Re: wal sync method

pgsql-patches by date

Next:From: Tom LaneDate: 2006-02-27 15:07:24
Subject: Re: Scrollable cursors and Sort performance
Previous:From: Peter EisentrautDate: 2006-02-27 12:55:04
Subject: Re: Uninstall scripts for contrib

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