Re: [PoC] Reducing planning time when tables have many partitions - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PoC] Reducing planning time when tables have many partitions
Date
Msg-id CAApHDvrRQ-HrgTByi6RrDd+yC6mMnnv_oh42HuwYQjQNEOGQ1Q@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Reducing planning time when tables have many partitions  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: [PoC] Reducing planning time when tables have many partitions
Re: [PoC] Reducing planning time when tables have many partitions
List pgsql-hackers
On Wed, 9 Apr 2025 at 17:09, Amit Langote <amitlangote09@gmail.com> wrote:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
>
>     An EquivalenceClass can contain "em_is_child" members, which are copies
>     of members that contain appendrel parent relation Vars, transposed to
>     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.
>
> The part about these being in the EquivalenceClass might be worth
> rewording now that we keep them in a separate array.

I did read over that as part of the search I did for things that need
to be updated, but I didn't see the need to adjust anything since the
text doesn't talk about where the members are stored.  The only thing
I see as a hint to that is the final sentence.

If the README is light on documentation about where members are
stored, do we really need to start detailing that because of this
change?  I've tried to be fairly comprehensive about where members are
stored in the header comment for struct EquivalenceClass. Wouldn't
stating something similar in the README just be duplicating that?  I
always think of the READMEs as more of an overview on how things fit
together with some high-level theory. I think talking about data
structures might be a bit too much detail.

I'm happy to view wording suggestions if you think we need to detail
this further. Maybe there's something that can be adjusted without
going into too much depth.

David



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Next
From: Ashutosh Bapat
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions