From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some thoughts about i/o priorities and throttling vacuum |
Date: | 2003-10-17 15:23:35 |
Message-ID: | 1066404215.77910.14.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> > What part of plain vacuum takes disk bandwidth?
>
> Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large number but not significant in memory usage) pages it has
deleted tuples out of and a second list of N pages it has inserted
tuples into.
After the transaction has completed and there is an idle period (say 1/4
second between transaction) it can pass the insert information on a
rollback and delete information on a commit to a separate backend.
This 'vacuum' backend could then prioritize garbage collection for the
pages it knows have been changed performing a single page vacuum when a
specific page has seen a high level of reported activity.
If this daemon could also get a hold of information about idleness of IO
in general the decision about what to vacuum and when may be better
(heavily hit pages during peak periods, all reports pages on medium
load). When completely idle, run through the entire system to get back
as much as possible.
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-10-17 15:29:54 | Re: Some more information_schema issues |
Previous Message | Christopher Browne | 2003-10-17 15:21:51 | Re: Some thoughts about i/o priorities and throttling vacuum |