pgstat_drop_relation bugfix - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject pgstat_drop_relation bugfix
Date
Msg-id 20070622140217.612A.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: DROP TABLE and autovacuum  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
I wrote:
> the runtime statistics are not invalidated -- it cound be a bug.
> pgstat_drop_relation() is expecting relid (pg_class.oid) as the argument,
> but we pass it relfilenode.
> 
> [storage/smgr/smgr.c]
> smgr_internal_unlink(RelFileNode rnode, int which, bool isTemp, bool isRedo)
>         pgstat_drop_relation(rnode.relNode);

I'm trying to fix the bug, because there is a possibility that some useless
statistics data continue to occupy some parts of the statistics table.

The bugfix itself is not so difficult; we only need to add a relid field
to PendingRelDelete structure and pass it to pgstat_drop_relation().
However, there are some design issues here.

- smgr need to know relation oid not only relfilenode.  This might brake the module independency.

- What should we do on TRUNCATE, CLUSTER and rewriting table?  The runtime statistics are still valid after those
commands practically, but we discard them in the current logic.  TRUNCATE should be set both n_live_tup and n_dead_tup
tozero.  CLUSTER and rewriting taable should be set only n_dead_tup to zero.  But it might be good to keep other
statistics(# of scans).
 

Are there any other more clever ways?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: autovacuum launcher continues to run after reloading autovacuum=off
Next
From: "Jaime Casanova"
Date:
Subject: Re: month abreviation