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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Damir Ciganović-Janković <damir(dot)ciganovic(dot)jankovic(at)gmail(dot)com>
Cc: Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15334: Partition elimination not working as expected when using enum as partition key
Date: 2018-08-17 11:21:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

>>>>> "Damir" == Damir Ciganović-Janković <damir(dot)ciganovic(dot)jankovic(at)gmail(dot)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.

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).

From JDBC, I believe there's an option to make setString pass parameters
as being unknown-type (oid 0) rather than as varchars. Maybe that would
be a possible workaround?

Andrew (irc:RhodiumToad)

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-08-17 11:47:11 BUG #15337: partition modify bug? cann't sync relcache in the same session immediate?
Previous Message Andrew Gierth 2018-08-17 10:27:46 Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)