To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: pgsql-performance@postgresql.org
Subject: Re: Planner reluctant to start from subquery 
In-reply-to: <43E0C4A7.EE98.0025.0@wicourts.gov> 
References: <43E0AA7E.EE98.0025.0@wicourts.gov>
	<43E0AA7E.EE98.0025.0@wicourts.gov> <3759.1138822464@sss.pgh.pa.us>
	<43E0BEDD.EE98.0025.0@wicourts.gov><43E0BEDD.EE98.0025.0@wicourts.gov>
	<4218.1138824885@sss.pgh.pa.us> <43E0C4A7.EE98.0025.0@wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Wed, 01 Feb 2006 14:24:39 -0600"
Date: Wed, 01 Feb 2006 15:36:15 -0500
Message-ID: <4359.1138826175@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>> I'm interested to poke at this ... are you in a position to provide a
>> test case?

> I can't supply the original data, since many of the tables have
> millions of rows, with some of the data (related to juvenile, paternity,
> sealed, and expunged cases) protected by law.  I could try to put
> together a self-contained example, but I'm not sure the best way to do
> that, since the table sizes and value distributions may be significant
> here.  Any thoughts on that?

I think that the only aspect of the data that really matters here is the
number of distinct values, which would affect decisions about whether
HashAggregate is appropriate or not.  And you could probably get the
same thing to happen with at most a few tens of thousands of rows.

Also, all we need to worry about is the columns used in the WHERE/JOIN
conditions, which looks to be mostly case numbers, dates, and county
identification ... how much confidential info is there in that?  At
worst you could translate the case numbers to some randomly generated
identifiers.

			regards, tom lane