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 DAB11D85D5 for ; Sun, 11 Sep 2005 21:34:27 -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 04656-04 for ; Mon, 12 Sep 2005 00:34:22 +0000 (GMT) Received: from ns.snowman.net (ns.snowman.net [66.92.160.21]) by svr1.postgresql.org (Postfix) with ESMTP id 7C03DD858C for ; Sun, 11 Sep 2005 21:34:22 -0300 (ADT) Received: by ns.snowman.net (Postfix, from userid 1000) id 7ED7617AD3; Sun, 11 Sep 2005 20:34:50 -0400 (EDT) Date: Sun, 11 Sep 2005 20:34:50 -0400 From: Stephen Frost To: Ksenia Marasanova Cc: pgsql-performance@postgresql.org Subject: Re: LEFT JOIN optimization Message-ID: <20050912003450.GD6026@ns.snowman.net> Mail-Followup-To: Ksenia Marasanova , pgsql-performance@postgresql.org References: <130df19305091110125a2d174f@mail.gmail.com> <20050911210035.GC6026@ns.snowman.net> <130df19305091114477e2e581b@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gkIXscVEwe9sR2ZH" Content-Disposition: inline In-Reply-To: <130df19305091114477e2e581b@mail.gmail.com> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.4.24ns.3.0 (i686) X-Uptime: 20:27:12 up 92 days, 16:43, 9 users, load average: 0.04, 0.06, 0.06 User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.004 required=5 tests=[AWL=0.004] X-Spam-Level: X-Archive-Number: 200509/133 X-Sequence-Number: 14441 --gkIXscVEwe9sR2ZH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ksenia Marasanova (ksenia.marasanova@gmail.com) wrote: > test=3D# explain analyze select * from user_ left join church on > user_.church_id =3D church.id; [...] > Total runtime: 2025.946 ms > (6 rows) >=20 > test=3D# set enable_seqscan=3D'false'; > SET > test=3D# explain analyze select * from user_ left join church on > user_.church_id =3D church.id; > =20 [...] > Total runtime: 2131.364 ms > (5 rows) >=20 >=20 > I followed some tips on the web and vacuum-ed database, I think the > query is faster now, almost acceptable, but still interesting to know > if it possible to optimize it... I have to say that it does seem a bit slow for only 12,000 rows.. What's the datatype of user_.church_id and church.id? Are you sure you really want all 12,000 rows every time you run that query? Perhaps there's a 'where' clause you could apply with an associated index to limit the query to just what you actually need? You'll noticed from above, though, that the non-index scan is faster. I'd expect that when using a left-join query: you have to go through the entire table on an open left-join like that, a sequencial scan is going to be the best way to do that. The fact that church.id is hashed makes the solution the planner came up with almost certainly the best one possible. Are you sure a left-join is what you want? Sounds like maybe you've moved (for some reason) from a regular join to a left join with a filtering in the application which is probably a bad move... If you can use at least some filtering in the database I expect that'd help.. Thanks, Stephen --gkIXscVEwe9sR2ZH 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) iD8DBQFDJM0qrzgMPqB3kigRAo3ZAJ0frqfYceegGylIhkOZQ65d76IjcQCfRxO6 hsNHlBuWhH0QAEtw1A+C8Ys= =oDN1 -----END PGP SIGNATURE----- --gkIXscVEwe9sR2ZH--