Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@persistent.co.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
