Re: Performance improvement for joins where outer side is unique
От | Tomas Vondra |
---|---|
Тема | Re: Performance improvement for joins where outer side is unique |
Дата | |
Msg-id | 54EF5C6C.6030001@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Performance improvement for joins where outer side is unique (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Performance improvement for joins where outer side is unique
|
Список | pgsql-hackers |
On 26.2.2015 18:34, Tom Lane wrote: > Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >> FWIW this apparently happens because the code only expect that >> EquivalenceMembers only contain Var, but in this particular case that's >> not the case - it contains RelabelType (because oprcode is regproc, and >> needs to be relabeled to oid). > > If it thinks an EquivalenceMember must be a Var, it's outright > broken; I'm pretty sure any nonvolatile expression is possible. I came to the same conclusion, because even with the RelabelType fix it's trivial to crash it with a query like this: SELECT 1 FROM pg_proc p JOIN pg_operator o ON oprcode = (p.oid::int4 + 1); I think fixing this (e.g. by restricting the optimization to Var-only cases) should not be difficult, although it might be nice to handle generic expressions too, and something like examine_variable() should do the trick. But I think UNIQUE indexes on expressions are not all that common. -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: