Re: [GENERAL] Creation of tsearch2 index is very slow

Поиск
Список
Период
Сортировка
От Ron
Тема Re: [GENERAL] Creation of tsearch2 index is very slow
Дата
Msg-id 7.0.1.0.2.20060120174141.039b03e8@earthlink.net
обсуждение исходный текст
Ответ на Re: [GENERAL] Creation of tsearch2 index is very slow  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: [GENERAL] Creation of tsearch2 index is very slow  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Re: [GENERAL] Creation of tsearch2 index is very slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [GENERAL] Creation of tsearch2 index is very slow  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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



В списке pgsql-performance по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: [GENERAL] Creation of tsearch2 index is very slow
Следующее
От: "Steinar H. Gunderson"
Дата:
Сообщение: Re: [GENERAL] Creation of tsearch2 index is very slow