David Rowley <dgrowleyml@gmail.com> writes:
> On Mon, 1 Feb 2021 at 18:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh, it's too late at night. I now remember that the real problem
>> I had with that representation was that it cannot work for joinrels.
>> Currently we only apply this logic to partitioned baserels, but
>> don't you think it might someday be called on to optimize
>> partitionwise joins?
> I've not looked in detail, but I think the code would need a pretty
> big overhaul before that could happen.
Yeah, there's no doubt that a lot of other work would be needed too;
I'd just figured that maybe this code could be ready for it. But on
looking at it again, I agree that the bitmapset approach is simpler
and cheaper than what I did. I realized that a good bit of what
I did not like about the pre-existing logic is that it was calling
the values "Relids" rather than Bitmapsets. To my mind, the Relids
typedef is meant to denote values that identify individual relations
(which might be joins) to the planner. The values we're dealing with
in this code do *not* correspond to anything that is or could be a
RelOptInfo; rather they are sets of distinct relations. It's fine
to use a Bitmapset if it's a convenient representation, but we should
call it that and not a Relids.
I renamed things that way, did some more work on the comments,
and pushed it. Thanks for reviewing!
regards, tom lane