Re: Remaining VACUUM patches - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: Remaining VACUUM patches
Date
Msg-id 20070419145356.6C4D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: Remaining VACUUM patches  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > The other patch was ITAGAKI Takahiro's patch to fix n_dead_tuples in
> > pgstats after VACUUM when there is concurrent update activity.
> 
> I objected (and still object) to this patch because it allows
> n_dead_tuples to drift arbitrarily far away from reality

> There was some discussion about better ways to do it, IIRC, but no new
> patch has been submitted.

I wrote the patch *after* the dicussion (and it is still valid with
some hunks). It sets n_dead_tuples as the follows:
                          | n_dead_tuples
---------------------------+---------------
(1) At the start of vacuum | N
(2) At the end of vacuum   | M (>=N)
(3) After updating stats   | M - N

So if we don't update the table during vacuum, n_dead_tuples will be
definitely zero. Even if there are some updates with inaccurate stats
in a vacuum, only the errors generated in the vacuum are left. Errors
generated before the vacuum are completely cleared so that the formula
does not enlarge the inaccuracy.

I've waited for the completion of "Recalculating OldestXmin in a
long-running vacuum" patch, because it changes the accuracy of (3).
But without the recalculating patch, I have no plan to modify my
n_dead_tuples patch any further.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Background LRU Writer/free list
Next
From: Zoltan Boszormenyi
Date:
Subject: parser dilemma