|From:||Amit Langote <amitlangote09(at)gmail(dot)com>|
|To:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|Cc:||Damir Ciganović-Janković <damir(dot)ciganovic(dot)jankovic(at)gmail(dot)com>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Aug 17, 2018 at 20:21 Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
> >>>>> "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.
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.
|Next Message||Tom Lane||2018-08-17 13:28:17||Re: Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker|
|Previous Message||Andrew Gierth||2018-08-17 11:49:19||Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)|