From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: updated SORT/LIMIT patch |
Date: | 2007-05-17 04:56:17 |
Message-ID: | 87k5v8yrny.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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 think it would be worthwhile adding a method to tuplesort to ask whether
>> random access is possible and how many tuples were actually kept. Then
>> nodeSort could ask it those values instead of just remembering what values
>> were requested.
>
> I disagree with this line of development, as it amounts to exposing
> tuplesort implementation details as API.
I'm not sure I agree. What's the difference if between using a boolean value
we pass to tuplesort requesting random access and using a boolean value we get
back from asking tuplesort?
The "tuples_needed" is a bit of a wart but then it's the same inevitable wart
as set_bound.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | FAST PostgreSQL | 2007-05-17 08:43:54 | Re: Updateable cursors patch |
Previous Message | Bruce Momjian | 2007-05-17 01:07:31 | Re: Implemented current_query |