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
concernto me.
>
One option could be to have a dedicated PgStat_StatRelFileNodeEntry and populate the related PgStat_StatTabEntry when
callingthe 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
