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

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Damir Ciganović-Janković <damir(dot)ciganovic(dot)jankovic(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, noreply(at)postgresql(dot)org
Subject: Re: BUG #15334: Partition elimination not working as expected when using enum as partition key
Date: 2018-08-17 08:46:44
Message-ID: dfd66017-7189-ad6b-1c5f-88e37f23ff56@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2018/08/17 16:17, Damir Ciganović-Janković wrote:
> I know about the issue and the fix, but this is a different bug, it seems
> to me. I will try to explain the issue to be more clear.
> This is the enum, table and its partitions:
> +++++++++++++++++++++++++++++
> create type ab as enum ('A', 'B');
> create table test (key ab not null) partition by list (key);
> create table test_a partition of test for values in ('A');
> create table test_b partition of test for values in ('B');
> +++++++++++++++++++++++++++++
>
> We are using Java, so this is the code:
> +++++++++++++++++++++++++++++
> try (Connection connection = DriverManager.getConnection(...);
> PreparedStatement stmt = connection.prepareStatement("EXPLAIN SELECT *
> FROM test WHERE key = ?::ab")) {
>
> stmt.setString(1, "A");
> try (ResultSet rs = stmt.executeQuery()) {
> while (rs.next()) {
> System.out.println(rs.getString(1));
> }
> }
> }
> +++++++++++++++++++++++++++++
> Simple select with enum value as a parameter. Note that we didn't put
> "::cstring" in query. This is the result of the EXPLAIN SELECT from the
> code:
> +++++++++++++++++++++++++++++
> Append (cost=0.00..109.25 rows=26 width=4)
> -> Seq Scan on test_a (cost=0.00..54.63 rows=13 width=4)
> Filter: (key = ('A'::cstring)::ab)
> -> Seq Scan on test_b (cost=0.00..54.63 rows=13 width=4)
> Filter: (key = ('A'::cstring)::ab)
> +++++++++++++++++++++++++++++
> I have put wireshark snoop in attachment where we can see that our java
> client is not the one adding the "::cstring" part into the code.

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. Partition
pruning not occurring may however have to do with the fact that
PreparedStatement is being used meaning the planner doesn't get a chance
to do perform the pruning, but then one would see "Filter: (key = $1)" in
the EXPLAIN output if that's the case. Sorry, I'm out of clues.

By the way, just to reconfirm if your Java application is connecting to
the same server as psql, what plan do you get when you try the same query
via psql connecting to the same server as the Java application?

I get this:

$ psql
Timing is on.
Line style is unicode.
psql (10.2)
Type "help" for help.

create type ab as enum ('A', 'B');
create table test (key ab not null) partition by list (key);
create table test_a partition of test for values in ('A');
create table test_b partition of test for values in ('B');

EXPLAIN SELECT * FROM test WHERE key = 'A'::ab;
QUERY PLAN
──────────────────────────────────────────────────────────────
Append (cost=0.00..83.75 rows=26 width=4)
-> Seq Scan on test_a (cost=0.00..41.88 rows=13 width=4)
Filter: (key = 'A'::ab)
-> Seq Scan on test_b (cost=0.00..41.88 rows=13 width=4)
Filter: (key = 'A'::ab)
(5 rows)

With 10.5, partition for 'B' is pruned.

$ psql
Timing is on.
Line style is unicode.
psql (10.5)
Type "help" for help.

EXPLAIN SELECT * FROM test WHERE key = 'A'::ab;
QUERY PLAN
──────────────────────────────────────────────────────────────
Append (cost=0.00..41.88 rows=13 width=4)
-> Seq Scan on test_a (cost=0.00..41.88 rows=13 width=4)
Filter: (key = 'A'::ab)
(3 rows)

Thanks,
Amit

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-08-17 09:28:41 BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
Previous Message jimmy 2018-08-17 08:20:46 Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker