On Mon, 18 Mar 2019 at 14:06, David Rowley <david.row...@2ndquadrant.com> wrote: > > On Mon, 18 Mar 2019 at 10:08, Tom Lane <t...@sss.pgh.pa.us> wrote: > > If that doesn't work (because we need the index info sooner), maybe we > > could consider never removing ECs from eq_classes, so that their indices > > never change, then teaching most/all of the loops over eq_classes to > > ignore entries with non-null ec_merged. But we probably want the indexing > > bitmapsets to reflect canonical EC numbers, so we'd still have to do some > > updating I fear -- or else be prepared to chase up the ec_merged links > > when using the index bitmaps. > > That's probably a better solution. Perhaps we can continue to nullify > the ec_members, then just skip eclasses with a NIL ec_members. I > avoided that in the patch because I was worried about what extension > might be doing, but if you think it's okay, then I can change the > patch.
I've modified the patch to do it this way. The only loop over eq_classes I saw outside of equivclass.c was in postgres_fdw.c. This just calls eclass_useful_for_merging() on each EC in the list. Instead of having that loop skip deleted ECs, I changed eclass_useful_for_merging() so that it just returns false for that case. The only other thing I change was to create a new function named get_common_eclass_indexes() which removes some duplicate code where we were getting ECs common to two relations. I also made it so this function does not allocate unnecessary Bitmapsets when the inputs are simple relations. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
eclass_indexes_v4.patch
Description: Binary data
