Re: B-Tree support function number 3 (strxfrm() optimization)

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Date: 2014-09-12 09:28:47
Message-ID: 5412BCCF.7040001@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/12/2014 12:46 AM, Peter Geoghegan wrote:
> On Thu, Sep 11, 2014 at 1:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I think I said pretty clearly that it was.
>
> I agree that you did, but it wasn't clear exactly what factors you
> were asking me to simulate.

All factors.

> Do you want me to compare the same string a million times in a loop,
> both with a strcoll() and with a memcmp()?

Yes.

> Should I copy it into a buffer to add a NUL byte?

Yes.

> Or should it be a new string each time, with a cache miss expected
> some proportion of the time?

Yes.

I'm being facetious - it's easy to ask for tests when you're not the one
running them. But seriously, please do run the all the tests that you
think make sense.

I'm particularly interested in the worst case. What is the worst case
for the proposed memcmp() check? Test that. If the worst case regresses
significantly, then we need to have a discussion of how likely that
worst case is to happen in real life, what the performance is like in
more realistic almost-worst-case scenarios, does it need to be tunable,
is the trade-off worth it, etc. But if the worst case regresses less
than, say, 1%, and there are some other cases where you get a 300% speed
up, then I think it's safe to say that the optimization is worth it,
without any more testing or discussion.
- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-09-12 09:37:18 Re: Patch to support SEMI and ANTI join removal
Previous Message David Rowley 2014-09-12 09:17:48 Re: Patch to support SEMI and ANTI join removal