Thread: Error correction for n_dead_tuples
Here is a patch discussed in http://archives.postgresql.org/pgsql-hackers/2007-02/msg00010.php Concurrent vacuum will save n_dead_tuples value at the beginning. Stats collector will be subtract the value from n_dead_tuples instead of setting it to zero. The statistics accuracy of n_dead_tuples will be better, especially just after finish of a vacuum. The behavior in VACUUM FULL is not changed because concurrent updates are not allowed during VACUUM FULL. Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
ITAGAKI Takahiro wrote:
> Here is a patch discussed in
> http://archives.postgresql.org/pgsql-hackers/2007-02/msg00010.php
>
> Concurrent vacuum will save n_dead_tuples value at the beginning.
> Stats collector will be subtract the value from n_dead_tuples
> instead of setting it to zero. The statistics accuracy of n_dead_tuples
> will be better, especially just after finish of a vacuum.
>
> The behavior in VACUUM FULL is not changed because concurrent updates
> are not allowed during VACUUM FULL.
>
> Comments welcome.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers reviews > and approves it. Please put this on hold until we decide what to do with Heikki's patch to update OldestXmin during vacuum. One idea is to count the tuples actually cleared during vacuum. Another idea is to reread pgstat data after each OldestXmin recalculation to get accurate dead tuple counting. Neither of these seem very satisfying. > --------------------------------------------------------------------------- > > ITAGAKI Takahiro wrote: > > Here is a patch discussed in > > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00010.php > > > > Concurrent vacuum will save n_dead_tuples value at the beginning. > > Stats collector will be subtract the value from n_dead_tuples > > instead of setting it to zero. The statistics accuracy of n_dead_tuples > > will be better, especially just after finish of a vacuum. > > > > The behavior in VACUUM FULL is not changed because concurrent updates > > are not allowed during VACUUM FULL. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > > Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://momjian.postgresql.org/cgi-bin/pgpatches > > > > It will be applied as soon as one of the PostgreSQL committers reviews > > and approves it. > > Please put this on hold until we decide what to do with Heikki's patch > to update OldestXmin during vacuum. > > One idea is to count the tuples actually cleared during vacuum. Another > idea is to reread pgstat data after each OldestXmin recalculation to get > accurate dead tuple counting. Neither of these seem very satisfying. OK. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera <alvherre@commandprompt.com> wrote: > Please put this on hold until we decide what to do with Heikki's patch > to update OldestXmin during vacuum. Yes, I think his patch is very useful, but it has a little conflict with my patch. > One idea is to count the tuples actually cleared during vacuum. Another > idea is to reread pgstat data after each OldestXmin recalculation to get > accurate dead tuple counting. Neither of these seem very satisfying. I'm thinking to use the larger value of follows: - dead tuples statistic count at the beginning of vacuum - count the tuples actually cleared during vacuum The latter is usually larger with Heikki's patch. In the other hand, the formar is larger in only cases when many DELETEs were rollbacked. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
This patch is no longer needed. We can revisit this during 8.4 to see if it is still needed now that we have HOT. --------------------------------------------------------------------------- ITAGAKI Takahiro wrote: > Here is a patch discussed in > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00010.php > > Concurrent vacuum will save n_dead_tuples value at the beginning. > Stats collector will be subtract the value from n_dead_tuples > instead of setting it to zero. The statistics accuracy of n_dead_tuples > will be better, especially just after finish of a vacuum. > > The behavior in VACUUM FULL is not changed because concurrent updates > are not allowed during VACUUM FULL. > > Comments welcome. > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +