Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 1. Grab the AutovacSchedule LWLock exclusively.
>> 2. Check to see if another worker is currently processing
>> that table; if so drop LWLock and go to next list entry.
>> 3. Recompute whether table needs vacuuming; if not,
>> drop LWLock and go to next entry. (This test covers the
>> case where someone vacuumed the table since you made your
>> list.)
>> 4. Put table OID into shared memory, drop LWLock, then
>> vacuum table.
>> 5. Clear current-table OID from shared memory, then
>> repeat for next list entry.
> The point I'm not very sure about is that this proposal means we need to
> do I/O with the AutovacSchedule LWLock grabbed, to obtain up-to-date
> stats.
True. You could probably drop the lock while rechecking stats, at the
cost of having to recheck for collision (repeat step 2) afterwards.
Or recheck stats before you start, but if collisions are likely then
that's a waste of time. But on the third hand, does it matter?
Rechecking the stats should be much cheaper than a vacuum operation,
so I'm not seeing that there's going to be a problem. It's not like
there are going to be hundreds of workers contending for that lock...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
