pgstat_drop_relation bugfix

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема pgstat_drop_relation bugfix
Дата
Msg-id 20070622140217.612A.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: DROP TABLE and autovacuum  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: autovacuum launcher continues to run after reloading autovacuum=off
Следующее
От: "Jaime Casanova"
Дата:
Сообщение: Re: month abreviation