On 12/12/22 8:15 AM, Drouvot, Bertrand wrote:
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 concern to me.
One option could be to have a dedicated PgStat_StatRelFileNodeEntry and
populate the related PgStat_StatTabEntry when calling the new to be created
pgstat_relfilenode_flush_cb()? (That's what we are doing currently to
flush some of the table stats to the database stats for example).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
