Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeremy Kerr <jk(at)ozlabs(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, 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: 2010-02-23 02:35:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Jeremy Kerr <jk(at)ozlabs(dot)org> writes:
> > Stephen,
> >> If the updated function is always faster when the overall string is at
> >> least, say, 16 characters long,
> > But that's not the case - the cost of the function (and the speedup from 
> > the previous version) depends on the number of spaces that there are at 
> > the end.
> Right, but there are certainly not more spaces than there are string
> characters ;-)
> I think Dimitri's idea is eminently worth trying.  In a string of less
> than, say, 16 bytes, the prospects of being able to win anything get
> much smaller compared to the prospects of wasting the extra loop
> overhead.  There is also a DBA psychology angle to it.  If you've got
> CHAR(n) for very small n, it's likely that the type is being used in the
> "canonical" fashion and there won't be many trailing blanks.  The case
> where we can hope to win is where we have CHAR(255) or some other
> plucked-from-the-air limit.

What ever happened to this patch?

  Bruce Momjian  <bruce(at)momjian(dot)us>
  PG East:
  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-02-23 02:37:24
Subject: Re: Streaming replication and pg_xlogfile_name()
Previous:From: Bruce MomjianDate: 2010-02-23 02:23:13
Subject: Re: updated hstore patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group