Horton

Re: Problem with default partition pruning

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

View thread View on postgr.es
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Thibaut Madelaine <thibaut.madelaine@dalibo.com>, Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>, "'Imai, Yoshikazu'" <imai.yoshikazu@jp.fujitsu.com>
Cc: "'PostgreSQL Hackers'" <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-25T00:21:06Z
Lists: pgsql-hackers 
Hi,

On 2019/03/23 2:36, Thibaut Madelaine wrote:
> 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)

The problem here is not really related to partition pruning, but another
problem I recently sent an email about:

https://www.postgresql.org/message-id/9813f079-f16b-61c8-9ab7-4363cab28d80%40lab.ntt.co.jp

The problem in this case is that *constraint exclusion* is not working,
because partition constraint is not loaded by the planner.  Note that
pruning is only used if a query specifies the parent table, not a partition.

Thanks,
Amit

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.