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

From: Thom Brown <thom(at)linux(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Date: 2014-04-03 17:23:02
Message-ID: CAA-aLv5myu39CKEWzSpDQNk7yEukCyJQh+agFZ0JRXWFnWtX0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3 April 2014 17:52, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Mon, Mar 31, 2014 at 7:35 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> Okay. Attached revision only trusts strxfrm() blobs (as far as that
>> goes) when the buffer passed to strxfrm() was sufficiently large that
>> the blob could fully fit.
>
> Attached revision has been further polished. I've added two additional
> optimizations:
>
> * Squeeze the last byte out of each Datum, so that on a 64-bit system,
> the full 8 bytes are available to store strxfrm() blobs.
>
> * Figure out when the strcoll() bttextfastcmp_locale() comparator is
> called, if it was called because a poor man's comparison required it
> (and *not* because it's the non-leading key in the traditional sense,
> which implies there are no poorman's normalized keys in respect of
> this attribute at all). This allows us to try and get away with a
> straight memcmp if and when the lengths of the original text strings
> match, on the assumption that when the initial poorman's comparison
> didn't work out, and when the string lengths match, there is a very
> good chance that both are equal, and on average it's a win to avoid
> doing a strcoll() (along with the attendant copying around of buffers
> for NULL-termination) entirely. Given that memcmp() is so much cheaper
> than strcoll() anyway, this seems like a good trade-off.

I'm getting an error when building this:

In file included from printtup.c:23:0:
../../../../src/include/utils/memdebug.h:21:31: fatal error:
valgrind/memcheck.h: No such file or directory
compilation terminated.
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -I../../../src/include
-D_GNU_SOURCE -c -o analyze.o analyze.c -MMD -MP -MF
.deps/analyze.Po
make[4]: *** [printtup.o] Error 1
make[4]: Leaving directory
`/home/thom/Development/postgresql/src/backend/access/common'
make[3]: *** [common-recursive] Error 2
make[3]: Leaving directory
`/home/thom/Development/postgresql/src/backend/access'
make[2]: *** [access-recursive] Error 2
make[2]: *** Waiting for unfinished jobs....

--
Thom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-04-03 18:05:49 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Peter Geoghegan 2014-04-03 16:52:25 Re: B-Tree support function number 3 (strxfrm() optimization)