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

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

From: Jeremy Kerr <jk(at)ozlabs(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 12:47:00
Message-ID: 200906262047.00727.jk@ozlabs.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

For the new function to be faster, we need to know that there are more 
than 6 (on average, depending on alignment) trailing spaces. The number 
of non-space characters in the string won't affect performance (other 
than that there is probably a correlation between total string length 
and number of spaces, but we can't be certain of that).

> If the new function is always slower, regardless of overall string
> length, when there's only 1 extra space at the end

Yes, that is correct.

Cheers,


Jeremy


In response to

Responses

pgsql-hackers by date

Next:From: Alexey BashtanovDate: 2009-06-26 12:54:22
Subject: BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation
Previous:From: Stephen FrostDate: 2009-06-26 12:12:12
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen

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