From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Jonathan Bartlett <johnnyb(at)eskimo(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Factoring where clauses through UNIONS take 2 |
Date: | 2003-04-24 21:47:04 |
Message-ID: | 24125.1051220824@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> The thing that I think is killing it is the constants. A view like:
> create view qv1 as select a as b from q1 union select b from q2;
> explain select * from qv1 where b=3;
> pushes down into the selects.
> create view qv1 as select a as b, 'b' from q1 union select b,'c' from q2;
> explain select * from qv1 where b=3;
> doesn't.
Good catch. It would work the way Jonathan wants if he explicitly
coerces all those literals in the view definition to text (or *some*
specific datatype, anyway).
The reason the planner won't push down is that the result type of the
UNION's second column is TEXT, while the result types of the individual
sub-selects are UNKNOWN, and there are semantic issues with pushing down
a qual past a datatype conversion: it might not mean quite the same thing.
(Consider text vs char(n) and significant-blanks rules, for instance.)
In this particular case, since the qual doesn't actually touch the
type-converted column, it would have been safe to push down, but the
planner doesn't make this test on a per-qual basis: if there are type
conversions anywhere in the UNION it just punts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-04-24 21:50:41 | Re: C++ and v7.3.2 |
Previous Message | Matthew Nuzum | 2003-04-24 21:31:33 | Re: [SQL] rewriting values with before trigger |