Re: [PATCH] Planner support function for generate_subscripts()

On 08/09/2026 03:21, shihao zhong wrote:
> * A dimension above the first is asked for on an array that is not a
>   constant.  One dimension of an array is never longer than the whole
>   array, so a large number is wrong here.
>
> 1000 fits neither case.
>
> I kept 0002 as its own patch.  It only changes a number in the catalog,
> and 0001 does not need it.  If people do not agree on the number, 0001
> can still go in.
I'd say that detecting the estimate_array_length's default value for the rows
number and returning constant 1000 as used before might make life of engineers
easier and query plans more stable during upgrade.
Hence, maybe it makes sense to follow the way of group-by estimations -
introduce something like one more 'isdefault' parameter to the
estimate_array_length?

Basically, this code looks good. But I'd like to see more assertions: if
something will be changed at the functions itself it would more quickly detect
issues in the prosupport routine. For example:
- Assert(req->root != NULL);
- Type of arg2
- Potentially, no more than 3 arguments of the function
- Maybe hard oid check on F_GENERATE_SUBSCRIPTS / F_GENERATE_SUBSCRIPTS_NODIR

This topic also raises the question of the practical usability of the average
total number of elements in an array column. Your tests highlight a gap in
estimates for more than two dimensions.

regards, Andrei Lepikhov,
pgEdge