Horton

Re: [PoC] Reducing planning time when tables have many partitions

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Yuya Watari <watari.yuya@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, jian he <jian.universality@gmail.com>, Alena Rybakina <lena.ribackina@yandex.ru>, Andrei Lepikhov <a.lepikhov@postgrespro.ru>, Thom Brown <thom@linux.com>, Zhang Mingli <zmlpostgres@gmail.com>
Date: 2025-04-10T03:03:02Z
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. Update wording in optimizer/README for EquivalenceClasses

  2. Speedup child EquivalenceMember lookup in planner

  3. Allow planner to use Merge Append to efficiently implement UNION

  4. Remove trailing zero words from Bitmapsets

  5. Make Vars be outer-join-aware.

  6. Avoid making commutatively-duplicate clauses in EquivalenceClasses.

On Wed, 9 Apr 2025 at 17:38, Amit Langote <amitlangote09@gmail.com> wrote:
> Still, maybe a tiny tweak to the last line could help steer readers
> right without diving into storage. How about:
>
> Most operations on EquivalenceClasses should ignore child members,
> which are stored separately from normal members.

I think the only part of the current text that makes me slightly
uncomfortable is the "ignore child members".  I don't mind your text,
but it does introduce detail about how the members are stored, which
isn't there before.

I think the "ignore child members" part could be fixed with:

--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -902,7 +902,7 @@ contain the equivalent child-relation variables or
expressions.  These
 members are *not* full-fledged members of the EquivalenceClass and do not
 affect the class's overall properties at all.  They are kept only to
 simplify matching of child-relation expressions to EquivalenceClasses.
-Most operations on EquivalenceClasses should ignore child members.
+Most operations on EquivalenceClasses needn't look at child members.

Would that be ok?

David