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 15:07:24
Message-ID: 19205.1141052844@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
>> 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.

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

That would be the hard way, primarily because it would require copying
and modifying the struct at each level of recursion --- which'd turn
what should be a nearly zero-cost patch into something with possibly
nontrivial cost.

Copy and modify is needed because as one descends through the plan tree
the requirements change.  For instance, MergeJoin requires mark/restore
capability of its right input, but this will never be a requirement
propagated from the top (or anyplace else).  Materialize on the other
hand should turn off some of the bits, since it won't pass backwards
scan or mark/restore calls down to its child.  These are trivial changes
to implement with a flag-word representation, not so with a struct.

If I saw a need for non-boolean parameters in this structure then maybe
I'd agree, but there's no evidence of a need for them.  What the child
plan nodes need to know is "will I get any mark/restore calls" and such
like, and those are certainly boolean conditions.

I'm envisioning coding like

ExecInitMergeJoin(MergeJoin *node, EState *estate, int flags)
...
	/* reject unsupported cases */
	Assert(!(flags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)));
...
	innerPlanState(mergestate) = ExecInitNode(innerPlan(node),
	                                          estate,
	                                          flags | EXEC_FLAG_MARK);

nodeSort.c would have a test like

	node->random = (flags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)) != 0;

etc etc.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-02-27 16:03:17
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Previous:From: Mark WoodwardDate: 2006-02-27 14:39:59
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....

pgsql-patches by date

Next:From: Simon RiggsDate: 2006-02-27 17:44:48
Subject: Re: Scrollable cursors and Sort performance
Previous:From: Simon RiggsDate: 2006-02-27 14:17:23
Subject: Re: Scrollable cursors and Sort performance

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