Re: Preserve index stats during ALTER TABLE ... TYPE ...
| От | Michael Paquier |
|---|---|
| Тема | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Дата | |
| Msg-id | aPCMFGpqUrGOzKf_@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Preserve index stats during ALTER TABLE ... TYPE ... (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Preserve index stats during ALTER TABLE ... TYPE ...
|
| Список | pgsql-hackers |
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. 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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: