| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | 1111hqshj(at)sina(dot)com |
| Cc: | "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Make NUM_XLOGINSERT_LOCKS configurable |
| Date: | 2024-01-10 02:38:17 |
| Message-ID: | 2266698.1704854297@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
<1111hqshj(at)sina(dot)com> writes:
> I recently used benchmarksql to evaluate the performance of postgresql. I achieved nearly 20% improvement
> with NUM_XLOGINSERT_LOCKS changed from 8 to 16 under some cases of high concurrency. I wonder whether
> it is feasible to make NUM_XLOGINSERT_LOCKS a configuration parameter, so that users can get easier to optimize
> their postgresql performance through this setting.
Making it an actual GUC would carry nontrivial costs, not least that
there are hot code paths that do "foo % NUM_XLOGINSERT_LOCKS" which
would go from a mask operation to a full integer divide. We are
unlikely to consider that on the basis of an unsupported assertion
that there's a performance gain under unspecified conditions.
Even with data to justify a change, I think it'd make a lot more sense
to just raise the constant value.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-01-10 02:40:12 | Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows |
| Previous Message | John Naylor | 2024-01-10 02:06:08 | Re: add AVX2 support to simd.h |