From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make additional use of optimized linear search routines |
Date: | 2022-09-21 05:40:13 |
Message-ID: | YyqjvS3HumArAxwq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 03, 2022 at 10:06:58AM +0900, Michael Paquier wrote:
> Ohoh. This sounds like a good idea to me, close to what John has
> applied lately. I'll take a closer look..
So, the two code paths patched here are rather isolated. The one in
TransactionIdIsInProgress() requires an overflowed set of subxids
still running, something similar to what the isolation test
subxid-overflow does. XidIsConcurrent() is also kind of hard to
reason about with a benchmark.
Anyway, I did not know about the work done with SIMD instructions in
pg_lfind.h and after playing the API I have run some micro benchmarks
with on pg_lfind32() and I can see some improvements. With a range of
100~10k elements in a fixed number of repeated calls with a for loop
and lfind(), I could not get up to the 40% speedup. That was somewhat
closer to 15%~20% on x86 and 20%~25% with arm64. There is a trend
where things got better with a higher number of elements with
lfind().
In short, switching those code paths to use the linear search routines
looks like a good thing in the long-term, so I would like to apply
this patch. If you have any comments or objections, please feel
free.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-09-21 05:40:34 | Re: Fix snapshot name for SET TRANSACTION documentation |
Previous Message | Fujii Masao | 2022-09-21 05:25:08 | Re: [PATCH]Feature improvement for MERGE tab completion |