Re: [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scalingfrom rw-conflict tracking in serializable transactions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scalingfrom rw-conflict tracking in serializable transactions
Дата
Msg-id CA+Tgmoart=qNk7V9rT+Qjjs=OQCUUF4y8o9dXOARhaEBBwaMWQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Aug 7, 2017 at 1:51 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> * the whole predicate.c stuff is written using SHM_QUEUE.  I suppose
>   SHM_QUEUE works just fine, but predicate.c was being written at about
>   the same time (or a bit earlier) than the newer ilist.c interface was
>   being created, which I think had more optimization work thrown in.
>   Maybe it would be good for predicate.c to ditch use of SHM_QUEUE and
>   use ilist.c interfaces instead?  We could even think about being less
>   strict about holding exclusive lock on SerializableFinished for the
>   duration of ClearOldPredicateLocks, i.e. use only a share lock and
>   only exchange for exclusive if a list modification is needed.

I think we should rip SHM_QUEUE out completely and get rid of it.  It
doesn't make sense to have two implementations, one of which by its
name is only for use in shared memory.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] why not parallel seq scan for slow functions
Следующее
От: Tom Lane
Дата:
Сообщение: [HACKERS] More fun with container types