From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Tobias Brox <tobixen(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: locking issue on simple selects? |
Date: | 2010-09-16 00:32:32 |
Message-ID: | 4C9165A0.4060003@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tobias Brox wrote:
> I think those pages probably should be merged ... hmm ... if
> I manage to solve my locking issues I should probably try and
> contribute to the wiki.
>
Certainly the 3rd one could be merged with one of the other two, and
maybe all merged into one. I haven't cleaned up that whole area in a
whole, it's due for a round of it soon. You're welcome to take a shot at
it. We can always revert any mistakes made.
>> reducing deadlock_timeout.
>>
>
> It's set to one second, and some of the jams we have been experiencing
> has lasted for several minutes. I also think it should say in the pg
> log if there is a deadlock situation?
deadlock_timeout is how long a process trying to acquire a lock waits
before it a) looks for a deadlock, and b) prints a report that it's
waiting into the logs when log_lock_waits is on. So if you're looking
for slow lock acquisition that's in the sub-second range, it can be
useful to reduce regardless of whether deadlock ever happens. That
doesn't sound like your situation though.
--
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance" Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book
From | Date | Subject | |
---|---|---|---|
Next Message | Anssi Kääriäinen | 2010-09-16 05:51:19 | Re: Performance problem with joined aggregate query |
Previous Message | Merlin Moncure | 2010-09-15 22:25:15 | Re: Performance problem with joined aggregate query |