Re: Piggybacking vacuum I/O - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Piggybacking vacuum I/O
Date
Msg-id 2e78013d0701230813i34b907bcha74bd52d2505b7af@mail.gmail.com
Whole thread Raw
In response to Re: Piggybacking vacuum I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 1/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Pavan Deolasee" <pavan.deolasee@gmail.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

pgsql-hackers by date:

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