Re: Speed up transaction completion faster after many relations are accessed in a transaction

Поиск
Список
Период
Сортировка
От Yura Sokolov
Тема Re: Speed up transaction completion faster after many relations are accessed in a transaction
Дата
Msg-id df6b68c68244bd61cd044a59115d699e6c42246f.camel@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Speed up transaction completion faster after many relations are accessed in a transaction  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Speed up transaction completion faster after many relations are accessed in a transaction  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Good day, David.

I'm looking on patch and don't get some moments.

`GrantLockLocal` allocates `LOCALLOCKOWNER` and links it into
`locallock->locallockowners`. It links it regardless `owner` could be
NULL. But then `RemoveLocalLock` does `Assert(locallockowner->owner != NULL);`.
Why it should not fail?

`GrantLockLocal` allocates `LOCALLOCKOWNER` in `TopMemoryContext`.
But there is single `pfree(locallockowner)` in `LockReassignOwner`.
Looks like there should be more `pfree`. Shouldn't they?

`GrantLockLocal` does `dlist_push_tail`, but isn't it better to
do `dlist_push_head`? Resource owners usually form stack, so usually
when owner searches for itself it is last added to list.
Then `dlist_foreach` will find it sooner if it were added to the head.

regards

---------

Yura Sokolov
Postgres Professional
y.sokolov@postgrespro.ru
funny.falcon@gmail.com





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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal for internal Numeric to Uint64 conversion function.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: LogwrtResult contended spinlock