Re: [PATCH] Planner support function for generate_subscripts() - Mailing list pgsql-hackers

From Andrew Krylosov
Subject Re: [PATCH] Planner support function for generate_subscripts()
Date
Msg-id CA+nn4-qK6_FPSVK6tf639Z_LzeKZp6AVKkzH41Ec53k_gWsL2w@mail.gmail.com
Whole thread
In response to Re: [PATCH] Planner support function for generate_subscripts()  (Priyanka S <developerette@gmail.com>)
List pgsql-hackers
On Sun, Sep 13, 2026 at 09:54:37PM -0400, shihao zhong wrote:
> v3 broke the CompilerWarnings CI task.  v4 attached fixes that; nothing
> else has changed.

Hi,

I applied v4 on top of 1a846a555a, built with cassert on macOS arm64,
and ran the regress, isolation and postgres_fdw suites. All passed.
planner_est also passed with 0001 alone.

I also checked int2[]::int4[] and text[]::varchar[] casts, and
domains over int[] with and without a CHECK constraint. These all
gave exact row estimates. For the non-inlinable SQL function, a
four-element argument gave an estimate of 4 with a custom plan and
10 with a generic plan.

Using the same default estimate as unnest() for an unknown array seems
reasonable to me. I think this is ready for a committer. One minor
comment:

+                     * All we have is estimate_array_length(), which counts
+                     * every element rather than the length of one dimension.
+                     * Those agree for 1-D arrays, and since dimension 1 was
+                     * requested it's fair to suppose that's what we have.  If
+                     * not we'll overestimate, but no per-dimension statistics
+                     * exist that could do better.

The statistics path uses the average number of distinct non-null
elements. A column of 2-by-20 arrays filled with 1 gave an estimate of 1
for dimension 1, whose actual length is 2. I'd mention that limitation
here, since the estimate can also be too low.

Best regards,
Andrew Krylosov



pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: Re: FIX: BUG #19687: ALTER SEQUENCE missing lock