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
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 |