| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | 1111hqshj(at)sina(dot)com, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Make NUM_XLOGINSERT_LOCKS configurable |
| Date: | 2024-01-10 04:30:23 |
| Message-ID: | 2332382.1704861023@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> This suggestion has showed up more than once in the past, and WAL
> insertion is a path that can become so hot under some workloads that
> changing it to a GUC would not be wise from the point of view of
> performance. Redesigning all that to not require a set of LWLocks
> into something more scalable would lead to better result, whatever
> this design may be.
Maybe. I bet just bumping up the constant by 2X or 4X or so would get
most of the win for far less work; it's not like adding a few more
LWLocks is expensive. But we need some evidence about what to set it to.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2024-01-10 04:33:51 | Re: speed up a logical replica setup |
| Previous Message | Michael Paquier | 2024-01-10 04:26:14 | Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed |