On Tue, Apr 21, 2009 at 12:05 PM, John L. Clark <[email protected]> wrote:
> On Tue, Apr 21, 2009 at 10:50 AM, Tom Lane <[email protected]> wrote:
>> In that case you're going to need to provide a reproducible test case,
>> 'cause it worksforme.
>
> Ok. I scaled back my example by just selecting 1000 "random" rows
> from each of the component tables. The resulting database dump should
> be attached to this email. I tried a very small subset (just 10
> rows), but the resulting tables were small enough that the query plans
> were changing to use scans. Note that I haven't actually run sample
> queries with this smaller dataset. I have only been inspecting the
> query plans of the two queries that I listed in my original message,
> and the results are the same, except that the magnitude of the costs
> are scaled down. This scaling leads to a smaller performance penalty,
> but the query plan still shows that the join filter is still not being
> pushed down in the case of the view (built from a union).
I posted this earlier, but I haven't seen it come through the mailing
list, perhaps because of the attachment. I have also posted the
attachment at <http://infinitesque.net/temp/union_performance_2009-04-21.postgresql.dump.gz>.
The MD5 checksum is "3942fee39318aa5d9f18ac2ef3c298cf". If the
original does end up coming through, I'm sorry about the redundant
post.
Take care,
John L. Clark
