Extent Locks

All,

Starting a new thread to avoid hijacking Heikki's original, but..

* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> Truncating a heap at the end of vacuum, to release unused space back to
> the OS, currently requires taking an AccessExclusiveLock. Although
> it's only held for a short duration, it can be enough to cause a
> hiccup in query processing while it's held. Also, if there is a
> continuous stream of queries on the table, autovacuum never succeeds
> in acquiring the lock, and thus the table never gets truncated.

Extent locking suffers from very similar problems and we really need
to improve this situation. With today's fast i/o systems, and massive
numbers of CPUs in a single system, it's absolutely trivial to have a
whole slew of processes trying to add data to a single relation and
that access getting nearly serialized due to everyone waiting on the
extent lock.

Perhaps one really simple approach would be to increase the size of
the extent which is created in relation to the size of the relation.
I've no clue what level of effort is involved there but I'm hoping
such an approach would help. I've long thought that it'd be very neat
if we could simply give each bulk-inserter process their own 1G chunk
to insert directly into w/o having to talk to anyone else. The
creation of the specific 1G piece could, hopefully, be made atomic
easily (either thanks to the OS or with our own locking), etc, etc.

I'm sure it's many bricks shy of a load, but I wanted to raise the
issue, again, as I've seen it happening on yet another high-volume
write-intensive system.

Thanks,

Stephen