From: | Ron <rjpeace(at)earthlink(dot)net> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgreSQL(dot)org |
Subject: | Re: [GENERAL] Creation of tsearch2 index is very slow |
Date: | 2006-01-20 22:46:34 |
Message-ID: | 7.0.1.0.2.20060120174141.039b03e8@earthlink.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2006-01-20 22:49:15 | Re: [GENERAL] Creation of tsearch2 index is very slow |
Previous Message | Marko Kreen | 2006-01-20 22:41:40 | Re: Page-Level Encryption |
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2006-01-20 22:49:15 | Re: [GENERAL] Creation of tsearch2 index is very slow |
Previous Message | Martijn van Oosterhout | 2006-01-20 22:33:27 | Re: [GENERAL] Creation of tsearch2 index is very slow |