Re: Checksum errors in pg_stat_database
От | Drouvot, Bertrand |
---|---|
Тема | Re: Checksum errors in pg_stat_database |
Дата | |
Msg-id | b636dfec-d34e-2a33-52ab-40461bd5e312@gmail.com обсуждение исходный текст |
Ответ на | Re: Checksum errors in pg_stat_database (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Checksum errors in pg_stat_database
|
Список | pgsql-hackers |
On 12/12/22 5:09 AM, Michael Paquier wrote: > On Sun, Dec 11, 2022 at 08:48:15PM -0500, Tom Lane wrote: >> I think a stats table indexed solely by relfilenode wouldn't be a great >> idea, because you'd lose all the stats about a table as soon as you >> do vacuum full/cluster/rewriting-alter-table/etc. Can we create two >> index structures over the same stats table entries, so you can look >> up by either relfilenode or OID? I'm not quite sure how to manage >> rewrites, where you transiently have two relfilenodes for "the >> same" table ... maybe we could allow multiple pointers to the same >> stats entry?? > > FWIW, I am not sure that I would care much if we were to dropped the > stats associated to a relfilenode on a rewrite. In terms of checksum > failures, tuples are deformed so if there is one checksum failure a > rewrite would just not happen. The potential complexity is not really > appealing compared to the implementation simplicity and its gains, and > rewrites are lock-heavy so I'd like to think that people avoid them > (cough).. Agree that this is less "problematic" for the checksum use case. On the other hand, losing IO stats (as the ones we could add later on, suggested by Andres up-thread) looks more of a concernto me. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: