From: Scott Ribe <scott_ribe@elevated-dev.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: regression in PG 15.1
Date: Mon, 28 Nov 2022 07:44:00 -0700
References: <D86D21A2-20CB-4E28-AF0A-8C2C0139DA97@elevated-dev.com>
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
In-Reply-To: <D86D21A2-20CB-4E28-AF0A-8C2C0139DA97@elevated-dev.com>
Message-Id: <31E8683D-121B-4428-823A-A626BCBC54CB@elevated-dev.com>
Archived-At: 
 <https://www.postgresql.org/message-id/31E8683D-121B-4428-823A-A626BCBC54CB%40elevated-dev.com>
Precedence: bulk

I should have noted that vacuum analyze on parent table did not help.

> On Nov 28, 2022, at 7:41 AM, Scott Ribe <scott_ribe@elevated-dev.com> =
wrote:
>=20
> Table is partitioned on a column tbl_id, with an increasing =
"transaction id".
>=20
>  select * from tbl where txid > something and tbl_id =3D someval;
>=20
> ^^^ works as normal, searches the single partition, taking 0.044ms
>=20
>  select * from tbl where txid > something and tbl_id =3D (select id =
from reftbl where name =3D 'someval');
>=20
> ^^^ fails to exclude partitions, kicks off parallel scans on all 142, =
takes 23,170ms
>=20
> Queries in question are NOT auto-generated from some ORM, so there is =
an obvious easy workaround. Before trying that, and before digging into =
full table defs here, does anyone have an idea how to nudge the planner =
toward excluding the partitions.
>=20
> --
> Scott Ribe
> scott_ribe@elevated-dev.com
> https://www.linkedin.com/in/scottribe/
>=20
>=20
>=20
>=20
>=20