Merlin Moncure writes:
>> On Tue, Apr 28, 2009 at 5:41 PM, Tom Lane wrote:
>>> [squint...] AFAICS the only *direct* cost component in pg_lock_status
>>> is the number of locks actually held or awaited. If there's a
>>> noticeable component that depends on max_locks_per_transaction, it must
>>>
On Tue, Apr 28, 2009 at 5:42 PM, Merlin Moncure wrote:
> On Tue, Apr 28, 2009 at 5:41 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> I have a unloaded development server running 8.4b1 that is returning
>>> from a 'select * from pg_locks' in around 5 ms. While the time itself
>>> is not a big
On Tue, Apr 28, 2009 at 5:41 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I have a unloaded development server running 8.4b1 that is returning
>> from a 'select * from pg_locks' in around 5 ms. While the time itself
>> is not a big deal, I was curious and tested querying locks on a fairly
>>
Merlin Moncure writes:
> I have a unloaded development server running 8.4b1 that is returning
> from a 'select * from pg_locks' in around 5 ms. While the time itself
> is not a big deal, I was curious and tested querying locks on a fairly
> busy (200-500 tps sustained) running 8.2 on inferior ha
I have a unloaded development server running 8.4b1 that is returning
from a 'select * from pg_locks' in around 5 ms. While the time itself
is not a big deal, I was curious and tested querying locks on a fairly
busy (200-500 tps sustained) running 8.2 on inferior hardware. This
returned (after an
