Re: BUG #15334: Partition elimination not working as expected whenusing enum as partition key

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: BUG #15334: Partition elimination not working as expected whenusing enum as partition key
Дата
Msg-id CA+HiwqHtvZHnLcP7qWLnJb4aeF1dU4p+J4ZJYU7B_V4qZdVoaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15334: Partition elimination not working as expected when using enum as partition key  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-bugs
On Fri, Aug 17, 2018 at 20:21 Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "Damir" == Damir Ciganović-Janković <damir.ciganovic.jankovic@gmail.com> writes:

 >> It's the Postgres EXPLAIN's code for expression deparsing that puts
 >> the '::cstring' there. I have to wonder why it couldn't just skip
 >> adding that and print it as simply 'A'::ab. However, I'm not sure if
 >> answer to that question is related to why partition pruning doesn't
 >> occur.

I think what's happening there is this: the parameter value needs a cast
from text to "ab"; this cast is an IO cast, so it becomes
enum_in(textout('A'),oid), and simplify_function can process
textout('A') as a constant (since textout is immutable) but not
enum_in('A',oid) (because enum_in is only stable, since it depends on
the enum label definitions). So the simplified expression becomes
('A'::cstring)::ab even though that's not actually a valid cast in
normal circumstances.

Ah, I see.

I haven't checked the partition code, but my guess is that since that's
not a constant (due to the stable cast), it can't be used for pruning in
pg10 (in pg11 it seems to get pruned at execution time).

Yeah, that indeed seems to be the problem.

Thanks,
Amit

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker