On 3 April 2014 17:52, Peter Geoghegan <p...@heroku.com> wrote:
> On Mon, Mar 31, 2014 at 7:35 PM, Peter Geoghegan <p...@heroku.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
make[4]: *** [printtup.o] Error 1
make[4]: Leaving directory
make[3]: *** [common-recursive] Error 2
make[3]: Leaving directory
make[2]: *** [access-recursive] Error 2
make[2]: *** Waiting for unfinished jobs....


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to