From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | hisanori(dot)kobayashi(dot)bp(at)nttdata(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table |
Date: | 2020-07-12 12:55:31 |
Message-ID: | CAPmGK15mzs+4PcHxKzidTo49ssMvUMVS0VaLcN+4=1fqXHorYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Jul 8, 2020 at 3:15 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> Maybe I'm missing something, but I
> suspect that hash partitioning would also have a similar issue,
Here is an example causing the same assertion failure:
create table hp_prefix_test (a int, b int, c int, d int) partition by
hash (a part_test_int4_ops, b part_test_int4_ops, c
part_test_int4_ops, d part_test_int4_ops);
create table hp_prefix_test_p1 partition of hp_prefix_test for values
with (modulus 2, remainder 0);
create table hp_prefix_test_p2 partition of hp_prefix_test for values
with (modulus 2, remainder 1);
explain (costs off) select * from hp_prefix_test where a = 1 and b is
null and c = 1 and d = 1;
where part_test_int4_ops is borrowed from insert.sql. For hash
partitioning, I think prefix is allowed to contain no clauses for
all/any of earlier partition keys unlike range partitioning, so I
modified the assertion test to avoid the failure.
While working on it, I noticed there is yet another issue in
generating pruning steps. This is the comment for
get_steps_using_prefix():
* To generate steps, step_lastexpr and step_lastcmpfn are appended to
* expressions and cmpfns, respectively, extracted from the clauses in
* 'prefix'. Actually, since 'prefix' may contain multiple clauses for the
* same partition key column, we must generate steps for various combinations
* of the clauses of different keys.
But part of that function assumes that prefix contains at most one
clause for each of middle partition keys, which causes the same
assertion failure when there are multiple clauses for the middle
partition keys in prefix. Here is an example using range partitioning
causing the failure:
create table rp_prefix_test3 (a int, b int, c int, d int) partition by
range(a, b, c, d);
create table rp_prefix_test3_p1 partition of rp_prefix_test3 for
values from (1, 1, 1, 0) to (1, 1, 1, 10);
create table rp_prefix_test3_p2 partition of rp_prefix_test3 for
values from (2, 2, 2, 0) to (2, 2, 2, 10);
explain (costs off) select * from rp_prefix_test3 where a >= 1 and b
>= 1 and b >= 2 and c >= 2 and d >= 0;
To fix, I modified that function (precisely,
get_steps_using_prefix_recurse()) to allow the middle partition keys
also to have multiple clauses in prefix.
Attached is an updated version of the patch.
Best regards,
Etsuro Fujita
Attachment | Content-Type | Size |
---|---|---|
prefix-efujita-v3.patch | application/octet-stream | 13.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-07-12 21:44:10 | Re: postgresql 12 runs out of memory when updating a partitioned table with subquery |
Previous Message | Max Vikharev | 2020-07-12 12:06:31 | Re: postgresql 12 runs out of memory when updating a partitioned table with subquery |