Horton

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

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dmitry Dolgov <9erthalion6@gmail.com>, tomas@vondra.me, vignesh C <vignesh21@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Richard Guo <guofenglinux@gmail.com>
Date: 2025-03-28T16:46:15Z
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.

Attachments

On Fri, Mar 28, 2025 at 12:01 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Comparing root->join_rel_hash with EC->ec_derives_hash in the context
> of initial hash table size is a thinko on my part. It's less likely
> that there will be 1000 subqueries (requiring 1000 PlannerInfos) each
> with more than 32 join rels than a query with 1000 equivalence classes
> in one PlannerInfo with more than 32 ec_derives. So if using a small
> initial hash table doesn't impact performance negatively, why not save
> some memory. Thinking more about it, we know the size of
> ec_derives_list when creating the hash table and we are using
> simplehash which uses its own fillfactor and its own logic to expand
> the hash table, I think we should just use the length of
> ec_derives_list as the initial size. What do you think?
>

PFA patches. 0001 and 0002 are the same as the previous set. 0003
changes the initial hash table size to the length of ec_derives.

-- 
Best Wishes,
Ashutosh Bapat