| From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Lock pileup causes server to stall |
| Date: | 2014-11-12 06:49:29 |
| Message-ID: | 9E96340C-89AD-4A7A-9C92-47A0C08DE1D8@krogh.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> On 10/11/2014, at 22.40, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> Josh Berkus wrote:
>> All,
>>
>> pg version: 9.3.5
>> RHEL 6.5
>> 128GB/32 cores
>> Configured with shared_buffers=16GB
>> Java/Tomcat/JDBC application
>>
>> Server has an issue that whenever we get lock waits (transaction lock
>> waits, usually on an FK dependancy) lasting over a minute or more than
>> 10 at once, *all* queries on the server slow to a crawl, taking 100X to
>> 400X normal execution times.
>
> Current FK checking makes you wait if the referenced tuple is modified
> on any indexed column, not just those that are actually used in
> foreign keys. Maybe this case would be sped up if we optimized that.
Even if it is an gin index that is being modified? seems like a harsh limitation to me.
Jesper
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2014-11-12 13:51:10 | Re: Lock pileup causes server to stall |
| Previous Message | Jeff Janes | 2014-11-11 17:33:08 | Re: Lock pileup causes server to stall |