From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | pgstat_drop_relation bugfix |
Date: | 2007-06-22 05:31:46 |
Message-ID: | 20070622140217.612A.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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 to zero.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-06-22 06:37:07 | Re: month abreviation |
Previous Message | ITAGAKI Takahiro | 2007-06-22 02:29:41 | Re: autovacuum launcher continues to run after reloading autovacuum=off |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-06-22 08:18:53 | Re: Load Distributed Checkpoints, take 3 |
Previous Message | Neil Conway | 2007-06-22 03:20:57 | Re: psql: flush output in cursor-fetch mode |