Hello Ashutosh and Andrey, On Wed, Sep 20, 2023 at 8:03 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > While working on RestrictInfo translations patch I was thinking on > these lines. [1] uses hash table for storing translated RestrictInfo. > An EC can have a hash table to store ec_member translations. The same > patchset also has some changes in the code which generates > RestrictInfo clauses from ECs. I think that code will be simplified by > your approach.
Thank you for sharing this. I agree that we have to avoid adding complexity to existing or future codes through my patch. As you say, this approach mentioned in the last email is helpful to simplify the code, so I will try it. On Fri, Sep 22, 2023 at 12:49 PM Lepikhov Andrei <a.lepik...@postgrespro.ru> wrote: > It is okay if we talk about the self-join-removal feature specifically > because joins are removed before an inheritance expansion. > But ec_source_indexes and ec_derive_indexes point to specific places in > eq_sources and eq_derives lists. If I removed an EquivalenceClass or a > restriction during an optimisation, I would arrange all indexes, too. > Right now, I use a workaround here and remove the index link without removing > the element from the list. But I'm not sure how good this approach can be in > perspective. > So, having eq_sources and eq_derives localised in EC could make such > optimisations a bit more simple. Thank you for pointing it out. The ec_source_indexes and ec_derive_indexes are just picked up from the previous patch, and I have not changed their design. I think a similar approach to EquivalenceMembers may be applied to RestrictInfos. I will experiment with them and share a new patch. -- Best regards, Yuya Watari
