Date: Mon, 25 Jun 2007 17:56:54 -0400
From: Stephen Frost <sfrost@snowman.net>
To: "Tyrrill, Ed" <tyrrill_ed@emc.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 
Message-ID: <20070625215654.GF7531@tamriel.snowman.net>
Mail-Followup-To: "Tyrrill, Ed" <tyrrill_ed@emc.com>,
	pgsql-performance@postgresql.org
References: <A23190A408F7094FAF446C1538222F76041E1C28@avaexch01.avamar.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="IsIRZ4DwzP0DcleK"
Content-Disposition: inline
In-Reply-To: <A23190A408F7094FAF446C1538222F76041E1C28@avaexch01.avamar.com>
User-Agent: Mutt/1.5.13 (2006-08-11)


--IsIRZ4DwzP0DcleK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Tyrrill, Ed (tyrrill_ed@emc.com) wrote:
> Based on all this we will be going with 8.2.4.1, but it seems like
> currently the query planner isn't choosing the best plan for this case.

Was the 'work_mem' set to the same thing on all these runs?  Also, you
might try increasing the 'work_mem' under 8.2.4, at least for this query
(you can set it by just doing: set work_mem =3D '2GB'; or similar in psql,
or you can change the default in postgresql.conf).

The big thing of note, it seems, is that you've got enough memory and
it's coming out faster when doing a hash-join vs. a sort + merge-join.
Could likely be because it doesn't think there's enough work memory
available for the hash, which might change based on the values it gets
=66rom the statistics on how frequently something shows up, etc.

	Enjoy,

		Stephen

--IsIRZ4DwzP0DcleK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGgDomrzgMPqB3kigRAhyYAKCFZKXqJlt4rRSVUwknk0IaFAByxACcCj0S
QQtrIiR0BQq9QcjhMsPo8Uo=
=r0Mu
-----END PGP SIGNATURE-----

--IsIRZ4DwzP0DcleK--