Re: Preserve index stats during ALTER TABLE ... TYPE ...
| От | Bertrand Drouvot |
|---|---|
| Тема | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Дата | |
| Msg-id | aPCWOTnvcg2jyQtn@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
| Ответ на | Re: Preserve index stats during ALTER TABLE ... TYPE ... (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: