From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: updated SORT/LIMIT patch |
Date: | 2007-05-17 14:16:06 |
Message-ID: | 24168.1179411366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> 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.
Right, but separating the child rescan from the tuplestore rescan bugs me.
Another problem is that the proposed patch does a child rescan call that
might (usually would) be unnecessary.
I am thinking that a cleaner fix is probably to make ExecRescanLimit do
the recompute_limits() bit immediately, so that the new limits are
available to the Sort node when it gets the rescan call. The comment
about timing of recompute_limits() is referring to the fact that
parameters aren't set at ExecInitLimit() time, but I believe they are
(and should be) available at Rescan time. Will give it a try anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-05-17 14:20:50 | Re: UTF8MatchText |
Previous Message | Gregory Stark | 2007-05-17 13:54:46 | Re: updated SORT/LIMIT patch |