On Tue, Apr 21, 2009 at 12:05 PM, John L. Clark <j...@po.cwru.edu> wrote: > On Tue, Apr 21, 2009 at 10:50 AM, Tom Lane <t...@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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
