Re: Speed up transaction completion faster after many relations are accessed in a transaction - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: Speed up transaction completion faster after many relations are accessed in a transaction
Date
Msg-id df6b68c68244bd61cd044a59115d699e6c42246f.camel@postgrespro.ru
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations are accessed in a transaction  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Speed up transaction completion faster after many relations are accessed in a transaction  (David Rowley <dgrowleyml@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposal for internal Numeric to Uint64 conversion function.
Next
From: Alvaro Herrera
Date:
Subject: Re: LogwrtResult contended spinlock