Re: Some thoughts about i/o priorities and throttling vacuum

Tom Lane wrote:

> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
>
>>Would it be possible to have a vacuum variant that would just shuffle thr.
>>shared buffers and not touch disk at all?
>
>
> What would be the use of that? You couldn't predict *anything* about
> the coverage. Maybe you find all the free space in a particular table,
> but most likely you don't.
>
> In any case an I/O-free vacuum is impossible since once you have decided
> to recycle a particular tuple, you don't have any option about removing
> the corresponding index entries first. So unless both the table and all
> its indexes are in RAM, you will be incurring I/O.

I am just suggesting it as a variant and not a replacement for existing vacuum
options. Knowing that it does not do any IO, it could be triggered lot more
aggressively. Furthermore if we assume pg_autovacuum as integral part of
database operation, right before from a single database object is created, I
think it could cover many/most database usage patterns barring multiple indexes,
for which normal vacuum variants could be used.

Furthermore, when a tuple is updated, all the relevant indexes are updated,
right? So if such a vacuum is aggressive enough, it could catch the index
entries as well, in the RAM.

Think of it like catching hens. Easier to do in a cage rather than over a farm.
So catch as many of them in cage. If they escape or spill out of cage due to
over-population, you have to tread the farm anyways...

Just a thought.

Shridhar