All,
Starting a new thread to avoid hijacking Heikki's original, but..
* Heikki Linnakangas (hlinnakangas@vmware.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
tryingto 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
sizeof the relation. I've no clue what level of effort is involved there but I'm hoping such an approach would help.
I'velong thought that it'd be very neat if we could simply give each bulk-inserter process their own 1G chunk to insert
directlyinto 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
anotherhigh-volume write-intensive system.
Thanks,
Stephen
