Re: Lock pileup causes server to stall

От: Jesper Krogh
Тема: Re: Lock pileup causes server to stall
Дата: ,
Msg-id: B69D0038-538E-4F15-961F-F5F31867E8AC@krogh.cc
(см: обсуждение, исходный текст)
Ответ на: Re: Lock pileup causes server to stall  (Alvaro Herrera)
Список: pgsql-performance

Скрыть дерево обсуждения

Lock pileup causes server to stall  (Josh Berkus, )
 Re: Lock pileup causes server to stall  (Alvaro Herrera, )
  Re: Lock pileup causes server to stall  (Jesper Krogh, )
   Re: Lock pileup causes server to stall  (Alvaro Herrera, )
    Re: Lock pileup causes server to stall  (Jesper Krogh, )
 Re: Lock pileup causes server to stall  (Josh Berkus, )
  Re: Lock pileup causes server to stall  (Jeff Janes, )
 Re: Lock pileup causes server to stall  (Josh Berkus, )

>>>>
>>>
>>> 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.
>
> Well, as I recall it's only unique indexes, so it's not *that* harsh.
>
Sounds good.   Indices are there for all kinds of reasons, unique ones are more related to referential integrity, so
evennot 100% accurate, at least 90% of the way in my world. 

We do have an "star"-schema in the db with some amount of information needed in the center that needs updates, apart
fromthat a massive update activity on the sorrounding columns, locks on the center entity has quite high impact on the
sorroundingupdates. (9.2 moving to 9.3 reallly soon and looking forward for this enhancement. 

Jesper


В списке pgsql-performance по дате сообщения:

От: Filip Rembiałkowski
Дата:
Сообщение: 9.0 performance degradation with kernel 3.11
От: CS DBA
Дата:
Сообщение: Increased shared_buffer setting = lower hit ratio ?