X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 066FED9D29 for ; Thu, 6 Oct 2005 15:50:14 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 61325-03 for ; Thu, 6 Oct 2005 18:50:07 +0000 (GMT) Received: from mail1.catalyst.net.nz (godel.catalyst.net.nz [202.78.240.40]) by svr1.postgresql.org (Postfix) with ESMTP id 08221D99E3 for ; Thu, 6 Oct 2005 15:50:04 -0300 (ADT) Received: from leibniz.catalyst.net.nz ([202.78.240.7] helo=lamb.mcmillan.net.nz) by mail1.catalyst.net.nz with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ENaod-0005Mv-2V; Fri, 07 Oct 2005 07:50:03 +1300 Received: from lamb.mcmillan.net.nz (lamb.mcmillan.net.nz [127.0.0.1]) by lamb.mcmillan.net.nz (Postfix) with ESMTP id 222917A00F7; Fri, 7 Oct 2005 07:50:02 +1300 (NZDT) Subject: Re: index on custom function; explain From: Andrew McMillan To: Jan Aerts Cc: pgsql-performance@postgresql.org In-Reply-To: <1128420628.326795.158780@g47g2000cwa.googlegroups.com> References: <1128352451.312090.37640@g44g2000cwa.googlegroups.com> <1128420628.326795.158780@g47g2000cwa.googlegroups.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lEDfzr2pG8VI9y7+7Tey" Date: Fri, 07 Oct 2005 07:50:01 +1300 Message-Id: <1128624601.17294.86.camel@lamb.mcmillan.net.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 required=5 tests=[FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200510/126 X-Sequence-Number: 14894 --=-lEDfzr2pG8VI9y7+7Tey Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-10-04 at 03:10 -0700, Jan Aerts wrote: > Some additional thoughts: what appears to take the most time (i.e. > account for the highest cost in the explain), is _not_ running the > function itself (cost=3D0.00..0.01), but comparing the result from that > function with the name1 column in the mappings table > (cost=3D0.00..35935.05). Am I right? (See EXPLAIN in previous post.) If > so: that's pretty strange, because the name1-column in the mappings > table is indexed... 35935.05 is for the loop, 0.01 is for the operation within the loop. What version of PostgreSQL is this? Some old versions were not good at handling the IN ( ... ) clause. Also, PostgreSQL doesn't always do a wonderful job of considering the activities of a function into the design of the query plans. Sometimes this can be a blessing, but not in this case. Cheers, Andrew. ------------------------------------------------------------------------- Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 It is truth which you cannot contradict; you can without any difficulty contradict Socrates. - Plato ------------------------------------------------------------------------- --=-lEDfzr2pG8VI9y7+7Tey Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDRXHZjJA0f48GgBIRAiALAKCdMFuYfQ7hR0YbJNkH9gJ9KWyG+gCfbB4v kPiwjm5zqGlu2jiA+pXV3f4= =jIXL -----END PGP SIGNATURE----- --=-lEDfzr2pG8VI9y7+7Tey--