Re: updated SORT/LIMIT patch - Mailing list pgsql-patches

From Gregory Stark
Subject Re: updated SORT/LIMIT patch
Date
Msg-id 87k5v8yrny.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: updated SORT/LIMIT patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: updated SORT/LIMIT patch  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
"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 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


pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Implemented current_query
Next
From: "FAST PostgreSQL"
Date:
Subject: Re: Updateable cursors patch