Re: Reducing ClogControlLock contention

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Reducing ClogControlLock contention
Дата
Msg-id CAA4eK1+6Nbs1eBSm6Uo2jnMHStnw6Etqr7OSu3aOQuZ7MbuWbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Reducing ClogControlLock contention  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Reducing ClogControlLock contention  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> ClogControlLock contention is high at commit time. This appears to be due to the fact that ClogControlLock is acquired in Exclusive mode prior to marking commit, which then gets starved by backends running TransactionIdGetStatus().
>
> Proposal for improving this is to acquire the ClogControlLock in Shared mode, if possible.
>

This approach looks good way for avoiding the contention around
ClogControlLock.  Few things that occurred to me while looking at
patch are that

a.  the semantics of new LWLock (CommitLock) introduced
by patch seems to be different in the sense that it is just taken in
Exclusive mode (and no Shared mode is required) as per your proposal. We
could use existing LWLock APi's, but on the other hand we could even
invent new LWLock API for this kind of locking.

b. SimpleLruReadPage_ReadOnly() - This API's is meant mainly for
read-access of page and the description also says the same, but now
we want to use it for updating page as well. It might be better to invent
similar new API or at the very least modify it's description.

> Two concurrent writers might access the same word concurrently, so we protect against that with a new CommitLock. We could partition that by pageno also, if needed.
>

I think it will be better to partition it or use it in some other way to avoid
two concurrent writers block at it, however if you want to first see the
test results with this, then that is also okay.

Overall the idea seems good to pursue, however I have slight feeling
that using 2 LWLocks (CLOGControlLock in shared mode and new
CommitLock in Exclusive mode) to set the transaction information
is somewhat odd, but I could not see any problem with it.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Reducing ClogControlLock contention