On Mon, 18 Mar 2019 at 14:06, David Rowley <david.rowley@2ndquadrant.com> wrote:
>
> On Mon, 18 Mar 2019 at 10:08, Tom Lane <tgl@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
