Re: Extent Locks

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extent Locks
Date: 2013-05-28 05:28:02
Message-ID: 51A44062.6080809@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/17/2013 11:38 AM, Robert Haas wrote:
> maybe with a bit of modest pre-extension.
When it comes to pre-extension, is it realistic to get a count of
backends waiting on the lock and extend the relation by (say) 2x the
number of waiting backends?

Getting a list of lock waiters is always a racey proposition, but in
this case we don't need an accurate count, only an estimate, and the
count can only grow between getting the count and completing the
relation extension. Assuming it's even remotely feasible to get a count
of lock waiters at all.

If there are lots of procs waiting to extend the relation a fair chunk
could be preallocated with posix_fallocate on supported platforms.

If it's possible this would avoid the need to attempt any
recency-of-last-extension based preallocation with the associated
problem of how to store and access the last-extended time efficiently,
while still hopefully reducing contention on the relation extension lock
and without delaying the backend doing the extension too much more.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-05-28 05:31:19 Re: Extent Locks
Previous Message Craig Ringer 2013-05-28 05:12:45 Re: commit fest schedule for 9.4