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
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) |