Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Дата
в 03:56:26
Msg-id
20220525035626.2nb3dhlp7zrcx7ft@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Andres Freund <andres@anarazel.de>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Andres Freund <andres@anarazel.de>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Daniel Gustafsson <daniel@yesql.se>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Andres Freund <andres@anarazel.de>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Jacob Champion <jchampion@timescale.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Andres Freund <andres@anarazel.de>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Tomas Vondra <tomas.vondra@enterprisedb.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Robert Haas <robertmhaas@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Andres Freund <andres@anarazel.de>
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) Ranier Vilela <ranier.vf@gmail.com>
Hi,

On 2022-05-24 13:23:43 -0300, Ranier Vilela wrote:
> It certainly helps, but I trust that's not the only reason, in all the
> tests I did, there was an improvement in performance, even before using
> this feature.
> If you look closely at GetSnapShotData() you will see that
> GetSnapshotDataReuse is called for all snapshots, even the new ones, which
> is unnecessary.

That only happens a handful of times as snapshots are persistently
allocated. Doing an extra GetSnapshotDataReuse() in those cases doesn't matter
for performance. If anything this increases the number of jumps for the common
case.


It'd be a huge win to avoid needing ProcArrayLock when reusing a snapshot, but
it's not at all easy to guarantee that it's correct / see how to make it
correct. I'm fairly sure it can be made correct, but ...


> Another example NormalTransactionIdPrecedes is more expensive than testing
> statusFlags.

That may be true when you count instructions, but isn't at all true when you
take into account that the cachelines containing status flags are hotly
contended.

Also, the likelihood of filtering out a proc due to
NormalTransactionIdPrecedes(xid, xmax) is *vastly* higher than the due to the
statusFlags check. There may be a lot of procs failing that test, but
typically there will be far fewer backends in vacuum or logical decoding.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Michael Paquier
Дата:
FAQ