On Mon, Nov 17, 2025 at 09:32:37PM -0500, Corey Huinker wrote:
> So I looked at the generator functions, hoping they'd have enough in common
> that they could be made generic. And they're just different enough that I
> think it's not worth it to try.
>
> But, if we don't care about the order of the combinations, I also don't
> think we need to expose the functions at all. We know exactly how many
> combinations there should be for any N attributes as each attribute must be
> unique. So if we have the right number of unique combinations, and they're
> all subsets of the first-longest, then we must have a complete set.
> Thoughts on that?
>
> Getting _too_ tight with the ordering and contents makes me concerned for
> the day when the format might change. We don't want to _fail_ an upgrade
> because some of the combinations were in the wrong order.
That's fair. The planner costing code pulling the stats numbers based
on the attributes was smart enough to not care much about the ordering
as far as I recall, but I'd rather make sure of that first. This
needs some careful lookup.
>> These don't make sense anyway because they have a predictible and
>> perfectly matching correlation relationship.
>>
>
> They do, for now, but are we willing to lock ourselves into that forever?
Perhaps not. I cannot say for sure what's the future is going to be
made of.
> Looking over those functions, they both could have use the same generator,
> but the dependencies-side decided that dependency order doesn't matter,
> which puts doubt in my head that the order is perfectly the same for both,
> so we'd better follow each individually IF we want to enforce order.
I'd try to look at the bits related to pg_dependencies and
pg_ndistinct as two separate concepts, at the end. They're sort of
alike, but have too many differences already.
--
Michael
