Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id a41f1309-019f-ef8b-f6e8-c92dbdfc8207@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>)
Responses Re: [HACKERS] path toward faster partition pruning
List pgsql-hackers
Thanks Rajkumar for the test case.

On 2017/10/27 17:05, Rajkumar Raghuwanshi wrote:
> while testing further this feature, I got a bug with partitions as foreign
> tables. Test case given below. Take a look.

[ ... ]

> 
> --PG-HEAD
> postgres=# EXPLAIN (COSTS OFF) SELECT t1.c FROM fplt1 t1, LATERAL (SELECT
> DISTINCT t2.c FROM fplt1 t2  WHERE  t2.c = t1.c ) q;
>                     QUERY PLAN
> --------------------------------------------------
>  Nested Loop
>    ->  Append
>          ->  Foreign Scan on ftplt1_p1 t1
>          ->  Foreign Scan on ftplt1_p2 t1_1
>    ->  Unique
>          ->  Append
>                ->  Foreign Scan on ftplt1_p1 t2
>                ->  Foreign Scan on ftplt1_p2 t2_1
> (8 rows)
> 
> --PG-HEAD +v5 patches
> postgres=# EXPLAIN (COSTS OFF) SELECT t1.c FROM fplt1 t1, LATERAL (SELECT
> DISTINCT t2.c FROM fplt1 t2  WHERE  t2.c = t1.c ) q;
> 
> *ERROR:  invalid expression for partition key*

I looked at this and it seems the error occurs not because partitions
being foreign tables, but because the new code is wrong to assume that
Param nodes can never appear in the clauses coming from baserestrictinfo.
When trying to do the plan-time pruning for the partitioned table
appearing inside the lateral subquery, there are Params in the clauses in
baserestrictinfo that the new pruning code was unprepared to handle.
Fixed the code to instead give up on plan-time pruning in such a case.

Attached updated set of patches.  In addition to fixing the above bug, it
also fixes one of the cases reported by Beena regarding default partition
pruning that I yesterday had given up on as being too difficult to
implement [1], but today found out is not that difficult to do [2].
Change summary:

0001: added some new tests
0002: no change
0003: fixed issue that Rajkumar reported (cope with Params properly)
0004: no change
0005: fix the case to prune the default partition when warranted (the
      issue reported by Beena)

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/0d6096e8-7c7b-afed-71d3-dca151306626%40lab.ntt.co.jp

[2]
https://www.postgresql.org/message-id/8499324c-8a33-4be7-9d23-7e6a95e60ddf%40lab.ntt.co.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: [HACKERS] MERGE SQL Statement for PG11
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] Burst in WAL size when UUID is used as PK whilefull_page_writes are enabled