Re: Remaining VACUUM patches

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>, heikki(at)enterprisedb(dot)com
Subject: Re: Remaining VACUUM patches
Date: 2007-04-19 06:22:32
Message-ID: 20070419145356.6C4D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zoltan Boszormenyi 2007-04-19 09:19:40 parser dilemma
Previous Message Greg Smith 2007-04-19 04:10:45 Re: Background LRU Writer/free list