Error correction for n_dead_tuples

Started by ITAGAKI Takahiroover 19 years ago6 messagespatches
Jump to latest
#1ITAGAKI Takahiro
itagaki.takahiro@oss.ntt.co.jp

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

Attachments:

n_dead_tuples.patchapplication/octet-stream; name=n_dead_tuples.patchDownload+30-19
#2Bruce Momjian
bruce@momjian.us
In reply to: ITAGAKI Takahiro (#1)
Re: Error correction for n_dead_tuples

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. +

#3Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Bruce Momjian (#2)
Re: Error correction for n_dead_tuples

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

#4Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#3)
Re: Error correction for n_dead_tuples

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. +

#5ITAGAKI Takahiro
itagaki.takahiro@oss.ntt.co.jp
In reply to: Alvaro Herrera (#3)
Re: Error correction for n_dead_tuples

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

#6Bruce Momjian
bruce@momjian.us
In reply to: ITAGAKI Takahiro (#1)
Re: Error correction for n_dead_tuples

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. +