X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id F3C409DCBA8
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 20 Jan 2006 18:46:44 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 97782-05
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 20 Jan 2006 18:46:45 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from smtpauth06.mail.atl.earthlink.net
	(smtpauth06.mail.atl.earthlink.net [209.86.89.66])
	by postgresql.org (Postfix) with ESMTP id 395499DCB99
	for <pgsql-performance@postgreSQL.org>;
	Fri, 20 Jan 2006 18:46:41 -0400 (AST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;
 d=earthlink.net;
	b=ZgFP5dKbFLgb1wku2yzRZQ1x4e8t2osrRhz0/pXDtaaanBD/yd+1EKG7+a0dZzOe;
	h=Received:Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [70.22.189.241] (helo=ron-6d52adff2a6.earthlink.net)
	by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34)
	id 1F051i-0001Sk-Vz; Fri, 20 Jan 2006 17:46:39 -0500
Message-Id: <7.0.1.0.2.20060120174141.039b03e8@earthlink.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 20 Jan 2006 17:46:34 -0500
To: Martijn van Oosterhout <kleptog@svana.org>,Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-performance@postgreSQL.org
From: Ron <rjpeace@earthlink.net>
Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
In-Reply-To: <20060120213754.GG31908@svana.org>
References: <43D0ED57.1020608@gmx.de> <17454.1137771321@sss.pgh.pa.us>
	<20060120170452.GC31908@svana.org> <26153.1137784469@sss.pgh.pa.us>
	<20060120201036.GE31908@svana.org> <26583.1137788505@sss.pgh.pa.us>
	<20060120205132.GF31908@svana.org> <26958.1137791955@sss.pgh.pa.us>
	<20060120213754.GG31908@svana.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ELNK-Trace: 
 acd68a6551193be5d780f4a490ca69563f9fea00a6dd62bc0c2d152795c79d13abd85c8893694cdb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 70.22.189.241
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.428 required=5 tests=[AWL=-0.051,
	DNS_FROM_RFC_ABUSE=0.479]
X-Spam-Score: 0.428
X-Spam-Level: 
X-Archive-Number: 200601/372
X-Sequence-Number: 16850

At 04:37 PM 1/20/2006, Martijn van Oosterhout wrote:
>On Fri, Jan 20, 2006 at 04:19:15PM -0500, Tom Lane wrote:
> >   %   cumulative   self              self     total
> >  time   seconds   seconds    calls  Ks/call  Ks/call  name
> >  98.96   1495.93  1495.93 33035195     0.00     0.00  hemdistsign
>
><snip>
>
> > So we gotta fix hemdistsign ...
>
>lol! Yeah, I guess so. Pretty nasty loop. LOOPBIT will iterate 8*63=504
>times and it's going to do silly bit handling on each and every
>iteration.
>
>Given that all it's doing is counting bits, a simple fix would be to
>loop over bytes, use XOR and count ones. For extreme speedup create a
>lookup table with 256 entries to give you the answer straight away...
For an even more extreme speedup, don't most modern CPUs have an asm 
instruction that counts the bits (un)set (AKA "population counting") 
in various size entities (4b, 8b, 16b, 32b, 64b, and 128b for 64b 
CPUs with SWAR instructions)?

Ron