Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Manu <manuelreyesbravo(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, jian he <jian(dot)universality(at)gmail(dot)com>, imchifan(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Date: 2026-09-25 19:35:18
Message-ID: CADkLM=cx2mVUFkK1ACcAGVbeLm5qLQsrpiuDR2biVYiRKwgExg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>
> One thing outside this bug, about why all 8 expressions were lost.
> import_expressions() stores a failed expression as NULL and keeps the
> others, per its comments, but extended_statistics_update() then drops
> the whole stxdexpr array when exprs_is_perfect is false. With one
> statistics object on the d_arr expression plus a domain-over-range
> one, master restores nothing for either; with the d_arr expression
> next to a plain one, it is restored. Is dropping all of them
> intended? I may be missing the reason. v2 removes the cause here,
> so this only matters for other rejections.
>

It's an unfortunate consequence of how expression stats are stored.

The pg_statistic_ext_data.stxdexpr array must be the same length as the
number of negative elements in pg_statistic_ext.stxkeys... so a stxkeys of
[2,4,-1,-3,-4] correlates stats from the attnum=2, attnum=4, and the first,
third, and fourth expressions defined for this very complicated and
hypothetical extended statistic.

In addition to being difficult to unpack (you can't just skip to the Nth
element, you have to count the expression and then stop on the Nth one)
[1], it also presents a problem when building such an array, as we either
could not store a NULL value for an element in the stxdexprs array or we
could not then reliably re-extract that data [2], or both, and in either
case the stats were incomplete, thus necessitating that they be rebuilt
post-upgrade anyway, reducing the benefit of making them
slightly-less-incomplete [3].

[1] It should be noted that other work on Join Statistics in v20 is
proposing to change this format, which will make regular stats import
marginally simpler.
[2] a good starting point in thread [4]:
https://www.postgresql.org/message-id/CADkLM=cPB_V+oV5d+5bfZGA_1Loa7iMmqXWj+SM-YGzxoUYrcQ@mail.gmail.com
[3] the whole thread:
https://www.postgresql.org/message-id/flat/CADkLM%3DcPB_V%2BoV5d%2B5bfZGA_1Loa7iMmqXWj%2BSM-YGzxoUYrcQ%40mail.gmail.com#6afd9a3c0f048ca3b8619c9b667f3adb

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Corey Huinker 2026-09-25 19:45:10 Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Previous Message Manu 2026-09-25 19:12:20 Re: autovacuum: automatically propagate updated parameters