Re: WHERE condition not being pushed down to union parts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John L(dot) Clark" <jlc6(at)po(dot)cwru(dot)edu>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: WHERE condition not being pushed down to union parts
Date: 2009-04-21 19:58:31
Message-ID: 10990.1240343911@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"John L. Clark" <jlc6(at)po(dot)cwru(dot)edu> writes:
> 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>.

Ah. The problem is that your view contains constants in the UNION arms:

CREATE VIEW uri_or_literal_object AS
SELECT literalproperties.subject, literalproperties.subject_term, literalproperties.predicate, literalproperties.predicate_term, literalproperties.object, 'L'::character(1) AS object_term, literalproperties.context, literalproperties.context_term, literalproperties.data_type, literalproperties.language FROM literalproperties
UNION ALL
SELECT relations.subject, relations.subject_term, relations.predicate, relations.predicate_term, relations.object, relations.object_term, relations.context, relations.context_term, NULL::bigint AS data_type, NULL::character varying(3) AS language FROM relations;

In 8.2 and 8.3, the planner is only smart enough to generate
inner-indexscan nestloop plans on UNIONs if all the elements of the
SELECT lists are simple variables (that is, table columns).
8.4 will be smarter about this.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2009-04-22 00:01:10 Re: performance for high-volume log insertion
Previous Message Stephen Frost 2009-04-21 19:25:31 Re: performance for high-volume log insertion