RE: Problem with default partition pruning

Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>

From: "Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp>
To: "'Amit Langote'" <Langote_Amit_f8@lab.ntt.co.jp>, "'Thibaut'" <thibaut.madelaine@dalibo.com>, "'Imai, Yoshikazu'" <imai.yoshikazu@jp.fujitsu.com>
Cc: "'PostgreSQL Hackers'" <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-19T07:01:09Z
Lists: pgsql-hackers
Hi Amit-san,

From: Amit Langote [mailto:Langote_Amit_f8@lab.ntt.co.jp]
Sent: Monday, March 18, 2019 6:44 PM
 
> Hosoya-san,
> 
> On 2019/03/15 15:05, Yuzuko Hosoya wrote:
> > Indeed, it's problematic.  I also did test and I found that this
> > problem was occurred when any partition didn't match WHERE clauses.
> > So following query didn't work correctly.
> >
> > # explain select * from test1_3 where (id > 0 and id < 30);
> >                            QUERY PLAN
> > -----------------------------------------------------------------
> >  Append  (cost=0.00..58.16 rows=12 width=36)
> >    ->  Seq Scan on test1_3_1  (cost=0.00..29.05 rows=6 width=36)
> >          Filter: ((id > 0) AND (id < 30))
> >    ->  Seq Scan on test1_3_2  (cost=0.00..29.05 rows=6 width=36)
> >          Filter: ((id > 0) AND (id < 30))
> > (5 rows)
> >
> > I created a new patch to handle this problem, and confirmed the query
> > you mentioned works as expected
> >
> > # explain select * from test1 where (id > 0 and id < 30) or (id > 220 and id < 230);
> >                                 QUERY PLAN
> > ----------------------------------------------------------------------
> > -----  Append  (cost=0.00..70.93 rows=26 width=36)
> >    ->  Seq Scan on test1_1_1  (cost=0.00..35.40 rows=13 width=36)
> >          Filter: (((id > 0) AND (id < 30)) OR ((id > 220) AND (id < 230)))
> >    ->  Seq Scan on test1_3_1  (cost=0.00..35.40 rows=13 width=36)
> >          Filter: (((id > 0) AND (id < 30)) OR ((id > 220) AND (id <
> > 230)))
> > (5 rows)
> >
> > v2 patch attached.
> > Could you please check it again?
> 
> I think the updated patch breaks the promise that get_matching_range_bounds won't set scan_default
> based on individual pruning value comparisons.  How about the attached delta patch that applies on
> top of your earlier v1 patch, which fixes the issue reported by Thibaut?
> 
Indeed.  I agreed with your proposal.
Also, I confirmed your patch works correctly.

Best regards,
Yuzuko Hosoya




Commits

  1. Don't constraint-exclude partitioned tables as much

  2. Apply constraint exclusion more generally in partitioning

  3. Improve pruning of a default partition

  4. Doc: Fix event trigger firing table

  5. Remove obsolete nbtree insertion comment.