"Gregory Stark" <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> This patch makes what was already a hack into a full-fledged crock (and
>> it's not just the self-doubting comments that make me distrust it).
>> I think we need to rip out this ad-hoc parameter change signaling code
>> and make it work through the regular chgParam mechanism. Not sure about
>> details though. There may be no clean solution short of folding
>> Sort and Limit into a single node type.
>
> Well I can't disagree, I always was concerned about the inter-node
> communication part. If I have power on the train I might look at it then but
> otherwise I'm offline until Monday.
I did in fact have power on the train and due the wonders of a local rsync'd
CVS repository I could even view cvs logs and diffs offline. It's interesting
how I've read all this code and comments several times and each time I get
more out of it.
It doesn't look like the timing of the ExecRescan is an issue at all. There
are plenty of nodes that Rescan their children much later than when they first
start up. Even Nested Loop does so.
I do still need to read more about parameters and how the parameter sets are
initially constructed. It would be nice to set it up so the sort node gets
signalled using the existing infrastructure.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com