From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yuya Watari <watari(dot)yuya(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Thom Brown <thom(at)linux(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Subject: | Re: [PoC] Reducing planning time when tables have many partitions |
Date: | 2025-04-09 05:34:27 |
Message-ID: | CAExHW5sDACPxROLY2v3BBumby+O28ud84njBx0CxsxJ3YrD54g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 9, 2025 at 10:51 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Wed, 9 Apr 2025 at 17:09, Amit Langote <amitlangote09(at)gmail(dot)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.
This change didn't require us to change the README indicates that the
README is at the right level. The code changes internally reorganize
how child EMs are stored within an EC, so changing the comments for
relevant structures seems good enough, not a change that should bubble
up to the README. The only change in the EC interface is the addition
of a new iterator method - maybe we could document that in README but
that too seems more detail than what README is about.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2025-04-09 05:38:31 | Re: [PoC] Reducing planning time when tables have many partitions |
Previous Message | David Rowley | 2025-04-09 05:21:12 | Re: [PoC] Reducing planning time when tables have many partitions |