| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: WAL Insertion Lock Improvements |
| Date: | 2023-12-19 04:00:29 |
| Message-ID: | 20231219040029.GA723774@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 25, 2023 at 04:43:16PM +0900, Michael Paquier wrote:
> 0001 has been now applied. I have done more tests while looking at
> this patch since yesterday and was surprised to see higher TPS numbers
> on HEAD with the same tests as previously, and the patch was still
> shining with more than 256 clients.
I found this code when searching for callers that use atomic exchanges as
atomic writes with barriers (for a separate thread [0]). Can't we use
pg_atomic_write_u64() here since the locking functions that follow should
serve as barriers?
I've attached a patch to demonstrate what I'm thinking. This might be more
performant, although maybe less so after commit 64b1fb5. Am I missing
something obvious here? If not, I might rerun the benchmarks to see
whether it makes any difference.
[0] https://www.postgresql.org/message-id/flat/20231110205128.GB1315705%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| barrier.patch | text/x-diff | 1.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2023-12-19 04:20:39 | Re: Clang optimiser vs preproc.c |
| Previous Message | Masahiko Sawada | 2023-12-19 03:00:22 | Re: Improve eviction algorithm in ReorderBuffer |