Re: Slow standby snapshot

Поиск
Список
Период
Сортировка
От Michail Nikolaev
Тема Re: Slow standby snapshot
Дата
Msg-id CANtu0oi6x1uHZi50_bMiZ4SgvSGqCZbKziYQLpx-o=YjMLN2Aw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow standby snapshot  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hello, Andres.

Could you please clarify how to better deal with the situation?

According to your previous letter, I think there was some
misunderstanding regarding the latest patch version (but I am not
sure). Because as far as understand provided optimization (lazily
calculated optional offset to the next valid xid) fits into your
wishes. It was described in the previous letter in more detail.

And now it is not clear for me how to move forward :)

There is an option to try to find some better data structure (like
some tricky linked hash map) but it is going to be huge changes
without any confidence to get a more effective version (because
provided changes make the structure pretty effective).

Another option I see - use optimization from the latest patch version
and get a significant TPS increase (5-7%) for the typical standby read
scenario. Patch is small and does not affect other scenarios in a
negative way. Probably I could make an additional set of some
performance tests and provide some simulation to prove that
pg_atomic_uint32-related code is correct (if required).

Or just leave the issue and hope someone else will try to fix it in
the future :)

Thanks a lot,
Michail.



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

Предыдущее
От: Daniel Fone
Дата:
Сообщение: Re: pgcrypto support for bcrypt $2b$ hashes
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: psql - add SHOW_ALL_RESULTS option