Re: Problem with default partition pruning

From: shawn wang <shawn(dot)wang(dot)pg(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Shawn Wang <shawn(dot)wang(at)highgo(dot)ca>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Yuzuko Hosoya <yuzukohosoya(at)gmail(dot)com>
Subject: Re: Problem with default partition pruning
Date: 2019-06-24 01:24:33
Message-ID: CA+T=_GXO__hc9fsw9zd_exZrVj_ZBrZGyma8ZSWHz+LTd6OBDw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro,
Thank you for your reply.
You can see that the mail start time is February 22. So I looked at the
latest version at that time. I found that v11.2 was the newest branch at
the time. So I tried to merge this patch into the code, and I found that
everything worked. So I tested on this branch and got the results.
You need to add the v4_default_partition_pruning.patch
<https://www.postgresql.org/message-id/attachment/100463/v4_default_partition_pruning.patch>
first,
and then add the
v3_ignore_contradictory_where_clauses_at_partprune_step.patch
<https://www.postgresql.org/message-id/attachment/100591/v3_ignore_contradictory_where_clauses_at_partprune_step.patch>
.
Otherwise, you will find some errors.
I hope this helps you.

Regards.

--
Shawn Wang

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 于2019年6月22日周六 上午4:03写道:

> On 2019-Jun-17, Shawn Wang wrote:
>
> > I tested different types of key values, and multi-level partitioned
> tables, and found no problems.
> > Only the SQL in the file of src/test/regress/results/partition_prune.out
> has a space that caused the regression test to fail.
>
> It's not clear to me what patch were you reviewing. The latest patch I
> see in this thread, in [1], does not apply in any branches. As another
> test, I tried to apply the patch on commit 489e431ba56b (before Tom's
> partprune changes in mid May); if you use "patch -p1
> --ignore-whitespace" it is accepted, but the failure case proposed at
> the start of the thread shows the same behavior (namely, that test1_def
> is scanned when it is not needed):
>
> 55432 12devel 23506=# create table test1(id int, val text) partition by
> range (id);
> create table test1_1 partition of test1 for values from (0) to (100);
> create table test1_2 partition of test1 for values from (150) to (200);
> create table test1_def partition of test1 default;
> explain select * from test1 where id > 0 and id < 30;
> CREATE TABLE
> Duración: 5,736 ms
> CREATE TABLE
> Duración: 5,622 ms
> CREATE TABLE
> Duración: 3,585 ms
> CREATE TABLE
> Duración: 3,828 ms
> QUERY PLAN
> ─────────────────────────────────────────────────────────────────
> Append (cost=0.00..58.16 rows=12 width=36)
> -> Seq Scan on test1_1 (cost=0.00..29.05 rows=6 width=36)
> Filter: ((id > 0) AND (id < 30))
> -> Seq Scan on test1_def (cost=0.00..29.05 rows=6 width=36)
> Filter: ((id > 0) AND (id < 30))
> (5 filas)
>
> Duración: 2,465 ms
>
>
> [1] https://postgr.es/m/00cf01d4eea7$afa43370$0eec9a50$@lab.ntt.co.jp
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-06-24 02:18:06 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Previous Message Tomas Vondra 2019-06-23 23:56:36 Re: Choosing values for multivariate MCV lists