Re: updated SORT/LIMIT patch
От | Gregory Stark |
---|---|
Тема | Re: updated SORT/LIMIT patch |
Дата | |
Msg-id | 873b1vr1w9.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: updated SORT/LIMIT patch (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: updated SORT/LIMIT patch
|
Список | pgsql-patches |
"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
В списке pgsql-patches по дате отправления: