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: 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 02:18:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hi Stephen,

> What would be really useful would be "best case" and "worst case"
> scenarios.

I've put together some data from a microbenchmark of the bcTrulen 
function, patched and unpatched.

As for best-case, if you have a long string of trailing spaces, we can 
go through them at theoretically one quarter of cost (a test benchmark 
on x86 shows an actual reduction of 11 to 3 sec with a string of 100 

Worst-case behaviour is with smaller numbers of spaces. Here are the 
transition points (ie, where doing the word-wise comparison is faster 
than byte-wise) that I see from my benchmark:

	align	spaces
		3	7
		2	6
		1	5
		0	4

 - where 'align' is the alignment of the first byte to compare (ie, at 
the end of the string). This is pretty much as-expected, as these 
transition points are the first opportunity that the new function has to 
do a word compare.

In the worst cases, I see a 53% cost increase on x86 (with the string 
'aaa ') and a 97% increase on PowerPC ('a  ').

So, it all depends on the number of padding spaces we'd expect to see on 
workload data. Fortunately, we see the larger reductions on the more 
expensive operations (ie, longer strings).



In response to


pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2009-06-26 02:41:37
Subject: query cancel issues in contrib/dblink
Previous:From: Tom LaneDate: 2009-06-26 00:50:02
Subject: Re: 8.4 RC1 union/nested select cast bug?

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