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 8D96B9DCA7B for ; Fri, 20 Jan 2006 18:57:27 -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 99549-07 for ; Fri, 20 Jan 2006 18:57:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svana.org (svana.org [125.62.94.225]) by postgresql.org (Postfix) with ESMTP id 773BF9DC98F for ; Fri, 20 Jan 2006 18:57:20 -0400 (AST) Received: from kleptog by svana.org with local (Exim 4.50) id 1F05C4-0001N3-OE; Sat, 21 Jan 2006 09:57:20 +1100 Date: Fri, 20 Jan 2006 23:57:20 +0100 From: Martijn van Oosterhout To: Ron Cc: Tom Lane , pgsql-performance@postgreSQL.org Subject: Re: [GENERAL] Creation of tsearch2 index is very slow Message-ID: <20060120225720.GI31908@svana.org> Reply-To: Martijn van Oosterhout 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> <7.0.1.0.2.20060120174141.039b03e8@earthlink.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kHRd/tpU31Zn62xO" Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060120174141.039b03e8@earthlink.net> X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: User-Agent: Mutt/1.5.9i X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kleptog@svana.org X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.129 required=5 tests=[AWL=0.129] X-Spam-Score: 0.129 X-Spam-Level: X-Archive-Number: 200601/375 X-Sequence-Number: 16853 --kHRd/tpU31Zn62xO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2006 at 05:46:34PM -0500, Ron wrote: > At 04:37 PM 1/20/2006, Martijn van Oosterhout wrote: > >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=20 > instruction that counts the bits (un)set (AKA "population counting")=20 > in various size entities (4b, 8b, 16b, 32b, 64b, and 128b for 64b=20 > CPUs with SWAR instructions)? Quite possibly, though I wouldn't have the foggiest idea how to get the C compiler to generate it. Given that even a lookup table will get you pretty close to that with plain C coding, I think that's quite enough for a function that really is just a small part of a much larger system... Better solution (as Tom points out): work out how to avoid calling it so much in the first place... At the moment each call to gtsvector_picksplit seems to call the distance function around 14262 times. Getting that down by an order of magnitude will help much much more. Have a nice day, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --kHRd/tpU31Zn62xO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD0WrQIB7bNG8LQkwRApsuAJ0V/pXBmYDiad9ugYq4EyPzt0z69ACeISvA 7fX/GIKw+dp6c7ER15r8jg0= =I2SA -----END PGP SIGNATURE----- --kHRd/tpU31Zn62xO--