Re: Slow standby snapshot - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Slow standby snapshot
Date
Msg-id CANtu0oi6x1uHZi50_bMiZ4SgvSGqCZbKziYQLpx-o=YjMLN2Aw@mail.gmail.com
Whole thread Raw
In response to Re: Slow standby snapshot  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Daniel Fone
Date:
Subject: Re: pgcrypto support for bcrypt $2b$ hashes
Next
From: Fabien COELHO
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option