Shridhar Daithankar <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
