Re: Factoring where clauses through UNIONS take 2
От | Tom Lane |
---|---|
Тема | Re: Factoring where clauses through UNIONS take 2 |
Дата | |
Msg-id | 24125.1051220824@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Factoring where clauses through UNIONS take 2 (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: Factoring where clauses through UNIONS take 2
|
Список | pgsql-general |
Stephan Szabo <sszabo@megazone23.bigpanda.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
В списке pgsql-general по дате отправления: