Re: Constraint exclusion in views
От | Claudio Freire |
---|---|
Тема | Re: Constraint exclusion in views |
Дата | |
Msg-id | CAGTBQpYf3EktbSBq6OPvuk0EdZQM7ZXz3Zz+CgYcnOrxJpkU=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Constraint exclusion in views (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-performance |
On Sun, Nov 4, 2012 at 2:32 PM, Claudio Freire <klaussfreire@gmail.com> wrote: >> Well, what "partition" actually means is "only bother to try constraint >> exclusion proofs on appendrel members". UNION ALL trees will get >> flattened into appendrels in some cases. In a quick look at the code, >> it seems like in recent releases the restrictions are basically that the >> UNION ALL arms have to (1) each be a plain SELECT from a single table >> with no WHERE restriction; (2) all produce the same column datatypes; >> and (3) not have any volatile functions in the SELECT lists. I might be >> missing something relevant to the OP's case, but it's hard to tell >> without a concrete example. > > I would think our view succeeds all those tests, but I'm not entirely > sure about 2. It does use coalesce too, but I really doubt coalesce is > volatile... right? > > I don't have access to the code during the weekend, but I'll check > first thing tomorrow whether we have some datatype inconsistencies I > didn't notice. > > Thanks for the hint. It was indeed a type mismatch, there was an int in one subquery that was a bigint in all the others. Thanks a lot.
В списке pgsql-performance по дате отправления: