Message-ID: <4206356C.9060308@arbash-meinel.com>
Date: Sun, 06 Feb 2005 09:19:08 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: lutzeb@aeccom.com
Cc: Greg Stark <gsstark@mit.edu>, pgsql-performance@postgresql.org,
	tgl@sss.pgh.pa.us
Subject: Re: query produces 1 GB temp file
References: <20050205182117.0125074@mail2.aeccom.com>
	<87y8e2kb8j.fsf@stark.xeocode.com> <42061B35.6000306@aeccom.com>
In-Reply-To: <42061B35.6000306@aeccom.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig3F92F2BCD0AF6B1A96F413FE"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3F92F2BCD0AF6B1A96F413FE
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dirk Lutzebaeck wrote:

> Greg,
>
> Thanks for your analysis. But I dont get any better after bumping 
> STATISTICS target from 10 to 200.
> explain analyze shows that the optimizer is still way off estimating 
> the rows. Is this normal? It still produces a 1 GB temp file.
> I simplified the query a bit, now only two tables are involved (bi, 
> df). I also vacuumed.


Are you just doing VACUUM? Or are you doing VACUUM ANALYZE? You might 
also try VACUUM ANALYZE FULL (in the case that you have too many dead 
tuples in the table).

VACUUM cleans up, but doesn't adjust any planner statistics without ANALYZE.

John
=:->


--------------enig3F92F2BCD0AF6B1A96F413FE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCBjVwJdeBCYSNAAMRAnRoAKCRdqa1y+To3TusqiejEFGqDjLMJwCgkuF4
UsCJ5jrsQBBMWZOHqHEVD6M=
=41zs
-----END PGP SIGNATURE-----

--------------enig3F92F2BCD0AF6B1A96F413FE--