Re: Checksum errors in pg_stat_database
От | Tom Lane |
---|---|
Тема | Re: Checksum errors in pg_stat_database |
Дата | |
Msg-id | 1906695.1670809695@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Checksum errors in pg_stat_database (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Checksum errors in pg_stat_database
Re: Checksum errors in pg_stat_database |
Список | pgsql-hackers |
Michael Paquier <michael@paquier.xyz> writes: > On Sun, Dec 11, 2022 at 04:51:49PM -0800, Andres Freund wrote: >> I think there's a good argument for starting to track some stats based on the >> relfilenode, rather the oid, because it'd allow us to track e.g. the number of >> writes for a relation too (we don't have the oid when writing out >> buffers). But that's a relatively large change... > Yeah. I was thinking among the lines of sync requests and sync > failures, as well. 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?? regards, tom lane
В списке pgsql-hackers по дате отправления: