Re: Problem with default partition pruning - Mailing list pgsql-hackers

From Thibaut Madelaine
Subject Re: Problem with default partition pruning
Date
Msg-id 6213e860-c93b-1934-f5d4-bc3f5999e3af@dalibo.com
Whole thread Raw
In response to Re: Problem with default partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Problem with default partition pruning
List pgsql-hackers
Le 22/03/2019 à 07:38, Amit Langote a écrit :
> Hosoya-san,
>
> On 2019/03/22 15:02, Yuzuko Hosoya wrote:
>> I understood Amit's proposal.  But I think the issue Thibaut reported would 
>> occur regardless of whether clauses have OR clauses or not as follows.
>> I tested a query which should output "One-Time Filter: false".
>>
>> # explain select * from test2_0_20 where id = 25;
>>                               QUERY PLAN                               
>> -----------------------------------------------------------------------
>>  Append  (cost=0.00..25.91 rows=6 width=36)
>>    ->  Seq Scan on test2_10_20_def  (cost=0.00..25.88 rows=6 width=36)
>>          Filter: (id = 25)
>>
> Good catch, thanks.
>
>> As Amit described in the previous email, id = 25 contradicts test2_0_20's
>> partition constraint, so I think this clause should be ignored and we can
>> also handle this case in the similar way as Amit proposal.
>>
>> I attached v1-delta-2.patch which fix the above issue.  
>>
>> What do you think about it?
> It looks fine to me.  You put the code block to check whether a give
> clause contradicts the partition constraint in its perfect place. :)
>
> Maybe we should have two patches as we seem to be improving two things:
>
> 1. Patch to fix problems with default partition pruning originally
> reported by Hosoya-san
>
> 2. Patch to determine if a given clause contradicts a sub-partitioned
> table's partition constraint, fixing problems unearthed by Thibaut's tests
>
> About the patch that Horiguchi-san proposed upthread, I think it has merit
> that it will make partprune.c code easier to reason about, but I think we
> should pursue it separately.
>
> Thanks,
> Amit

Hosoya-san, very good idea to run queries directly on tables partitions!

I tested your last patch and if I didn't mix up patches on the end of a
too long week, I get a problem when querying the sub-sub partition:

test=# explain select * from test2_0_10 where id = 25;
                         QUERY PLAN                        
------------------------------------------------------------
 Seq Scan on test2_0_10  (cost=0.00..25.88 rows=6 width=36)
   Filter: (id = 25)
(2 rows)


Cordialement,

Thibaut



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Error message inconsistency
Next
From: Fabien COELHO
Date:
Subject: Re: Offline enabling/disabling of data checksums