Re: regression in PG 15.1

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: regression in PG 15.1
Date: 2022-11-28 14:50:08
Message-ID: CAKFQuwam1bzKUVEfruZZv8jGddTf3xrHQ4fNKaGwySXi_L=35Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Mon, Nov 28, 2022 at 7:45 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Scott Ribe <scott_ribe(at)elevated-dev(dot)com> writes:
> > select * from tbl where txid > something and tbl_id = (select id from
> reftbl where name = 'someval');
> > ^^^ fails to exclude partitions, kicks off parallel scans on all 142,
> takes 23,170ms
>
> Why do you say this is a regression? From what I know of the partition
> pruning logic (admittedly not a whole lot), I don't think we'd have
> ever pruned on the basis of such a constraint.
>
>
The second bullet point here indicates the subquery should prune during
execution.

https://www.postgresql.org/docs/15/ddl-partitioning.html#DDL-PARTITION-PRUNING

During actual execution of the query plan. Partition pruning may also be
performed here to remove partitions using values which are only known
during actual query execution. This includes values from subqueries [...]

That subquery seems like it should meet whatever criteria there is for this
runtime pruning. Namely, it must return zero or one rows and it not
correlated with the rest of the query.

David J.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Scott Ribe 2022-11-28 14:57:16 Re: regression in PG 15.1
Previous Message Tom Lane 2022-11-28 14:44:50 Re: regression in PG 15.1