Re: [PoC] Reducing planning time when tables have many partitions
От | Amit Langote |
---|---|
Тема | Re: [PoC] Reducing planning time when tables have many partitions |
Дата | |
Msg-id | CA+HiwqE8v=EuAP_3F_A2xn8zWx+nG_etW_Fe_DvKO-Fkx=+DdQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Reducing planning time when tables have many partitions (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: [PoC] Reducing planning time when tables have many partitions
Re: [PoC] Reducing planning time when tables have many partitions |
Список | pgsql-hackers |
Hi David, On Wed, Apr 9, 2025 at 5:12 AM David Rowley <dgrowleyml@gmail.com> wrote: > On Wed, 9 Apr 2025 at 02:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > David Rowley <dgrowleyml@gmail.com> writes: > > > I've pushed the patch now. Thanks for all the reviews of my adjustments. > > > > Shouldn't the CF entry be marked committed? > > I've done that now. 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. -- Thanks, Amit Langote
В списке pgsql-hackers по дате отправления: