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

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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +