Re: [PATCH] backend: compare word-at-a-time in bcTruelen

From: Jeremy Kerr <jk(at)ozlabs(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Date: 2009-06-26 03:20:39
Message-ID: 200906261120.39718.jk@ozlabs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> > I've put together some data from a microbenchmark of the bcTrulen
> > function, patched and unpatched.
>
> Uh, where's the data?

If you're after the raw data for a run, I've put it up:

http://ozlabs.org/~jk/projects/db/data/bctruelen.csv

I've also packaged up the quick-and-dirty benchmark I've been using:

http://ozlabs.org/~jk/projects/db/bctrulen.tar.gz

to recreate as-needed. ./benchmark.sh will run tests for varying-length
strings (so changing the alignment) and varying numbers of trailing
spaces. ./benchmark-bctruelen <str> will perform an individual old/new
comparison.

> Unfortunately, the cases with lots of padding spaces are probably
> much less probable than the cases with fewer. It would be unpleasant
> for example if this patch resulted in a severe performance
> degradation for a "canonical" example of char(n) being used properly,
> such as char(2) for US state abbreviations.

Yep, makes sense. The other consideration is stock-ticker symbols, I
assume they may also be stored in CHAR(small n) columns.

Cheers,

Jeremy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-06-26 04:08:37 [PATCH] [v8.5] Security checks on largeobjects
Previous Message Tom Lane 2009-06-26 02:48:58 Re: [PATCH] backend: compare word-at-a-time in bcTruelen