From: | Christopher Browne <cbbrowne(at)libertyrms(dot)info> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Some thoughts about i/o priorities and throttling vacuum |
Date: | 2003-10-17 15:21:51 |
Message-ID: | 60r81bubxs.fsf@dev6.int.libertyrms.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
shridhar_daithankar(at)persistent(dot)co(dot)in (Shridhar Daithankar) writes:
> Andrew Sullivan wrote:
>
>> On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
>>
>>> I am slightly confused here. IIRC pg_autovacuum never did a vacuum
>>> full. At the most it does vacuum /vacuum analyse, none of which
>>> chew disk bandwidth.
>> The latter is false. VACUUM FULL certainly uses _more_ disk
>> bandwidth than VACUUM, but it's just false that plain VACUUM doesn't
>> contend for disk. And if you're already maxed, then that extra
>> bandwidth you cannot afford.
>
> What part of plain vacuum takes disk bandwidth? WAL? Clog? Certainly
> not data files themselves, right?
Certainly YES, the data files themselves.
VACUUM has to read through the pages to assess what tuples are to
expire. So if the data file is 8GB long, VACUUM has to read through
8GB of data.
As compared to VACUUM FULL, it is certainly cheaper, as it is not
rummaging around to reorder pages, but rather walking through, single
page by single page. Thus, where VACUUM FULL might involve (in
effect) reading through the file several times (as it shifts data
between pages), VACUUM only reads through it once.
That's (for the "for instance") 8GB of reads.
--
"cbbrowne","@","libertyrms.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-10-17 15:23:35 | Re: Some thoughts about i/o priorities and throttling vacuum |
Previous Message | Andrew Sullivan | 2003-10-17 15:19:05 | Re: Some thoughts about i/o priorities and throttling vacuum |