Re: WHERE condition not being pushed down to union parts

On Tue, Apr 21, 2009 at 12:05 PM, John L. Clark <jlc6@po.cwru.edu> wrote:
> On Tue, Apr 21, 2009 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> 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