Re: Piggybacking vacuum I/O

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Piggybacking vacuum I/O
Date: 2007-01-23 16:13:50
Message-ID: 2e78013d0701230813i34b907bcha74bd52d2505b7af@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/23/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > Would it help to set the status of the XMIN/XMAX of tuples early enough
> such
> > that the heap page is still in the buffer cache, but late enough such
> that
> > the XMIN/XMAX transactions are finished ? How about doing it when the
> > bgwriter is about to write the page to disk ?
>
> No. The bgwriter would then become subject to deadlocks because it
> would be needing to read in clog pages before it could flush out
> dirty pages. In any case, if the table is in active use then some
> passing backend has probably updated the bits already ...

Well, let me collect some evidence. If we figure out that there is indeed a
CLOG buffer thrash at VACUUM time, I am sure we would be able to solve
the problem one way or the other.

IMHO this case would be more applicable to the very large tables where the
UPDATEd rows are not accessed again for a long time. And hence the hint bits
might not have been updated.

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-01-23 16:20:32 "tupdesc reference is not owned by resource owner Portal" issue in 8.2 and -HEAD
Previous Message Joshua D. Drake 2007-01-23 16:02:41 Re: 10 weeks to feature freeze (Pending Work)