Skip site navigation (1) Skip section navigation (2)

Re: WHERE condition not being pushed down to union parts

From: "John L(dot) Clark" <jlc6(at)po(dot)cwru(dot)edu>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: WHERE condition not being pushed down to union parts
Date: 2009-04-21 18:11:36
Message-ID: 4fb69e5d0904211111o125fee0u22bdfc6dda71ec9f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Apr 21, 2009 at 12:05 PM, John L. Clark <jlc6(at)po(dot)cwru(dot)edu> wrote:
> On Tue, Apr 21, 2009 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Kenneth MarshallDate: 2009-04-21 18:34:22
Subject: Re: performance for high-volume log insertion
Previous:From: davidDate: 2009-04-21 18:09:18
Subject: Re: performance for high-volume log insertion

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group