Re: heap vacuum & cleanup locks

On Thu, Nov 3, 2011 at 7:15 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> A while
>> back, someone (Greg Stark? me?) floated the idea of not waiting for
>> the cleanup lock.  If we can't get it immediately, or within some
>> short period of time, then we just skip the page and continue on.
>
> Separately, that sounds like a great idea and it's simple to implement
> - patch attached.

Oh, that's kind of clever. I was thinking that you'd have to disable
this entirely for anti-wraparound vacuum, but the way you've done it
avoids that. You'll still have to wait if there's a competing pin on
a buffer that contains tuples actually in need of freezing, but that
should be relatively rare.

> Enhancements to that are that I don't see any particular reason why
> Also, ISTM that LockBufferForCleanup() waits for just a single buffer,
> but it could equally well wait for multiple buffers at the same time.
> By this, we would then be able to simply register our interest in
> multiple buffers and get woken as soon as one of them were free. That
> way we could read the blocks sequentially, but lock and clean them out
> of sequence if necessary. Do this in chunks, so it plays nicely with
> buffer strategy. (Patch doesn't do that yet).

I doubt this would help much. The real issue is with open cursors,
and those can easily be left open for long enough that those
optimizations won't help. I think the patch as it stands is probably
gets just about all of the benefit that can be had from this approach
while still being reasonably simple.

> (Not sure if the patch handles vacuum map correctly if we skip the
> page, but its a reasonable prototype for discussion).

Yeah. I think that should be OK, but:

- It looks to me like you haven't done anything about the second heap
pass. That should probably get a similar fix.
- I think that this is going to screw up the reltuples calculation
unless we fudge it somehow. The number of scanned pages has already
been incremented by the time your new code is reached.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company