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  (David Rowley <dgrowleyml@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Precedence of standard comparison operators
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Reduce pinning in btree indexes