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

From Greg Stark
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM-w4HPOoY3UZv8Wd4EhGbTPKmOD0425hsGfZsdi8=A7wUjyzw@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization)
List pgsql-hackers

On Fri, Apr 4, 2014 at 12:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
>
> +1

+1

I don't think we have to promise a strict priority queue and preempt all other development. But I agree loosely that processing patches that have been around should be a higher priority.

I've been meaning to do more review for a while and just took a skim through the queue. There are only a couple I feel I can contribute with so I'm going to work on those and then if it's still before the feature freeze I would like to go ahead with Peter's patch. I think it's generally a good patch.

Two questions I have:

1) Would it make more sense to use a floating point instead of an integer? I saw a need for a function like this when I was looking into doing GPU sorts. But GPUs expect floating point values. 

2) I would want to see a second data type, probably numeric, before committing to be sure we had a reasonably generic api. But it's pretty simply to do so.


--
greg

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Pending 9.4 patches
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: Add ALTER TABLESPACE ... MOVE command