Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM3SWZQMx=qOenXY7bT+Zg-ouBuQn1KhgPgvBA5z0S1=Rv25LQ@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 3, 2014 at 11:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Personally, I have paid no attention to this thread and have no intention
> of doing so before feature freeze.

Anything that you missed was likely musings on how to further
generalize SortSupport. The actual additions to SortSupport and
tuplesort proposed are rather small. A simple abstraction to allow for
semi-reliable normalized keys, and a text sort support function to use
it.

> Perhaps I shouldn't lay my own guilt trip on other committers --- but
> I think it would be a bad precedent to not deal with the existing patch
> queue first.

I think that that's a matter of personal priorities for committers. I
am not in a position to tell anyone what their priorities ought to be,
and giving extra attention to this patch may be unfair. It doesn't
have to be a zero-sum game, though. Attention from a committer to,
say, this patch does not necessarily have to come at the expense of
another, if for example this patch piques somebody's interest and
causes them to put extra work into it on top of what they'd already
planned to look at. Again, under these somewhat unusual circumstances,
that seems like something that some committer might be inclined to do,
without it being altogether unreasonable. Then again, perhaps not.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: four minor proposals for 9.5
Next
From: Dean Rasheed
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)