Horton

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

Richard Guo <guofenglinux@gmail.com>

View thread
From: Richard Guo <guofenglinux@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-08-08T10:38:30Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add assertion to verify derived clause has constant RHS

  2. Make derived clause lookup in EquivalenceClass more efficient

  3. Doc: improve documentation for jsonpath behavior.

  4. Work around implementation restriction in adjust_appendrel_attrs.

On Thu, Jul 27, 2023 at 10:06 PM Ashutosh Bapat <
ashutosh.bapat.oss@gmail.com> wrote:

> 0002 - WIP patch to avoid repeated translations of RestrictInfo.
> The WIP patch avoids repeated translations by tracking the child for
> which a RestrictInfo is translated and reusing the same translation
> every time it is requested. In order to track the translations,
> RestrictInfo gets two new members.
> 1. parent_rinfo - In a child's RestrictInfo this points to the
> RestrictInfo applicable to the topmost parent in partition hierarchy.
> This is NULL in the topmost parent's RestrictInfo
> 2. child_rinfos - In a parent's RestrictInfo, this is a list that
> contains all the translated child RestrictInfos. In child
> RestrictInfos this is NULL.


I haven't looked into the details but with 0002 patch I came across a
crash while planning the query below.

regression=# set enable_partitionwise_join to on;
SET
regression=# EXPLAIN (COSTS OFF)
SELECT * FROM prt1 t1, prt2 t2
WHERE t1.a = t2.b AND t1.a < 450 AND t2.b > 250 AND t1.b = 0;
server closed the connection unexpectedly

Thanks
Richard