Hi,
On Thu, Oct 16, 2025 at 03:09:24PM +0900, Michael Paquier wrote:
> On Thu, Oct 16, 2025 at 01:38:19AM -0400, Tom Lane wrote:
> > Michael Paquier <michael@paquier.xyz> writes:
> >> Hmm. Why should it be always OK to preserve the stats of an index
> >> when one of its attributes is changed so as a relation is rewritten?
> >
> > Right offhand, this proposal seems utterly unsafe, to the point of
> > maybe introducing security-grade bugs. I see that the patch compares
> > opfamilies but that seems insufficient, since "same opfamily" does not
> > mean "binary compatible". We could easily be restoring stats whose
> > binary content is incompatible with the new column type.
>
> The point of the thread is about copying the aggregated numbers stored
> in pgstats. These numbers have a fixed size, for contents in
> PgStat_StatTabEntry. The point of the patch is about copying these
> entries in the pgstats hash table across rewrites, so I am not sure to
> follow your argument.
Same here.
> My point was slightly different: I am questioning if a reset does not
> make more sense in most cases as an attribute type change may cause
> the planner to choose a different Path, making the new stats generated
> leading to decisions that are inconsistent when aggregated with the
> numbers copied across the rewrites.
See my reply in [1].
[1]: https://www.postgresql.org/message-id/aPCVvWZjvvC1ZO78%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
