public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v7 2/3] Remove "dead" flag from catcache tuple 6+ messages / 4 participants [nested] [flat]
* [PATCH v7 2/3] Remove "dead" flag from catcache tuple @ 2020-11-18 07:57 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Kyotaro Horiguchi @ 2020-11-18 07:57 UTC (permalink / raw) --- src/backend/utils/cache/catcache.c | 43 +++++++++++++----------------- src/include/utils/catcache.h | 10 ------- 2 files changed, 18 insertions(+), 35 deletions(-) diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c index 644d92dd9a..611b65168d 100644 --- a/src/backend/utils/cache/catcache.c +++ b/src/backend/utils/cache/catcache.c @@ -480,6 +480,13 @@ CatCacheRemoveCTup(CatCache *cache, CatCTup *ct) Assert(ct->refcount == 0); Assert(ct->my_cache == cache); + /* delink from linked list if not yet */ + if (ct->cache_elem.prev) + { + dlist_delete(&ct->cache_elem); + ct->cache_elem.prev = NULL; + } + if (ct->c_list) { /* @@ -487,14 +494,10 @@ CatCacheRemoveCTup(CatCache *cache, CatCTup *ct) * which will recurse back to me, and the recursive call will do the * work. Set the "dead" flag to make sure it does recurse. */ - ct->dead = true; CatCacheRemoveCList(cache, ct->c_list); return; /* nothing left to do */ } - /* delink from linked list */ - dlist_delete(&ct->cache_elem); - /* * Free keys when we're dealing with a negative entry, normal entries just * point into tuple, allocated together with the CatCTup. @@ -534,7 +537,7 @@ CatCacheRemoveCList(CatCache *cache, CatCList *cl) /* if the member is dead and now has no references, remove it */ if ( #ifndef CATCACHE_FORCE_RELEASE - ct->dead && + ct->cache_elem.prev == NULL && #endif ct->refcount == 0) CatCacheRemoveCTup(cache, ct); @@ -609,7 +612,9 @@ CatCacheInvalidate(CatCache *cache, uint32 hashValue) if (ct->refcount > 0 || (ct->c_list && ct->c_list->refcount > 0)) { - ct->dead = true; + dlist_delete(&ct->cache_elem); + ct->cache_elem.prev = NULL; + /* list, if any, was marked dead above */ Assert(ct->c_list == NULL || ct->c_list->dead); } @@ -688,7 +693,8 @@ ResetCatalogCache(CatCache *cache) if (ct->refcount > 0 || (ct->c_list && ct->c_list->refcount > 0)) { - ct->dead = true; + dlist_delete(&ct->cache_elem); + ct->cache_elem.prev = NULL; /* list, if any, was marked dead above */ Assert(ct->c_list == NULL || ct->c_list->dead); } @@ -1268,9 +1274,6 @@ SearchCatCacheInternal(CatCache *cache, { ct = dlist_container(CatCTup, cache_elem, iter.cur); - if (ct->dead) - continue; /* ignore dead entries */ - if (ct->hash_value != hashValue) continue; /* quickly skip entry if wrong hash val */ @@ -1522,7 +1525,6 @@ ReleaseCatCache(HeapTuple tuple) offsetof(CatCTup, tuple)); /* Safety checks to ensure we were handed a cache entry */ - Assert(ct->ct_magic == CT_MAGIC); Assert(ct->refcount > 0); ct->refcount--; @@ -1530,7 +1532,7 @@ ReleaseCatCache(HeapTuple tuple) if ( #ifndef CATCACHE_FORCE_RELEASE - ct->dead && + ct->cache_elem.prev == NULL && #endif ct->refcount == 0 && (ct->c_list == NULL || ct->c_list->refcount == 0)) @@ -1737,8 +1739,8 @@ SearchCatCacheList(CatCache *cache, { ct = dlist_container(CatCTup, cache_elem, iter.cur); - if (ct->dead || ct->negative) - continue; /* ignore dead and negative entries */ + if (ct->negative) + continue; /* ignore negative entries */ if (ct->hash_value != hashValue) continue; /* quickly skip entry if wrong hash val */ @@ -1799,14 +1801,13 @@ SearchCatCacheList(CatCache *cache, { foreach(ctlist_item, ctlist) { + Assert (ct->cache_elem.prev != NULL); + ct = (CatCTup *) lfirst(ctlist_item); Assert(ct->c_list == NULL); Assert(ct->refcount > 0); ct->refcount--; if ( -#ifndef CATCACHE_FORCE_RELEASE - ct->dead && -#endif ct->refcount == 0 && (ct->c_list == NULL || ct->c_list->refcount == 0)) CatCacheRemoveCTup(cache, ct); @@ -1834,9 +1835,6 @@ SearchCatCacheList(CatCache *cache, /* release the temporary refcount on the member */ Assert(ct->refcount > 0); ct->refcount--; - /* mark list dead if any members already dead */ - if (ct->dead) - cl->dead = true; } Assert(i == nmembers); @@ -1960,11 +1958,9 @@ CatalogCacheCreateEntry(CatCache *cache, HeapTuple ntp, Datum *arguments, * Finish initializing the CatCTup header, and add it to the cache's * linked list and counts. */ - ct->ct_magic = CT_MAGIC; ct->my_cache = cache; ct->c_list = NULL; ct->refcount = 0; /* for the moment */ - ct->dead = false; ct->negative = negative; ct->hash_value = hashValue; ct->lastaccess = catcacheclock; @@ -2158,9 +2154,6 @@ PrintCatCacheLeakWarning(HeapTuple tuple) CatCTup *ct = (CatCTup *) (((char *) tuple) - offsetof(CatCTup, tuple)); - /* Safety check to ensure we were handed a cache entry */ - Assert(ct->ct_magic == CT_MAGIC); - elog(WARNING, "cache reference leak: cache %s (%d), tuple %u/%u has count %d", ct->my_cache->cc_relname, ct->my_cache->id, ItemPointerGetBlockNumber(&(tuple->t_self)), diff --git a/src/include/utils/catcache.h b/src/include/utils/catcache.h index 291e857e38..53b0bf31eb 100644 --- a/src/include/utils/catcache.h +++ b/src/include/utils/catcache.h @@ -87,9 +87,6 @@ typedef struct catcache typedef struct catctup { - int ct_magic; /* for identifying CatCTup entries */ -#define CT_MAGIC 0x57261502 - uint32 hash_value; /* hash value for this tuple's keys */ /* @@ -106,19 +103,12 @@ typedef struct catctup dlist_node cache_elem; /* list member of per-bucket list */ /* - * A tuple marked "dead" must not be returned by subsequent searches. - * However, it won't be physically deleted from the cache until its - * refcount goes to zero. (If it's a member of a CatCList, the list's - * refcount must go to zero, too; also, remember to mark the list dead at - * the same time the tuple is marked.) - * * A negative cache entry is an assertion that there is no tuple matching * a particular key. This is just as useful as a normal entry so far as * avoiding catalog searches is concerned. Management of positive and * negative entries is identical. */ int refcount; /* number of active references */ - bool dead; /* dead but not yet removed? */ bool negative; /* negative cache entry? */ HeapTupleData tuple; /* tuple management header */ uint64 lastaccess; /* timestamp in us of the last usage */ -- 2.27.0 ----Next_Part(Wed_Jan_27_10_13_08_2021_482)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v7-0003-catcachebench.patch" ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Speed up COPY FROM text/CSV parsing using SIMD @ 2026-01-13 19:12 Mark Wong <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Mark Wong @ 2026-01-13 19:12 UTC (permalink / raw) To: Nazir Bilal Yavuz <[email protected]>; +Cc: Manni Wood <[email protected]>; KAZAR Ayoub <[email protected]>; Nathan Bossart <[email protected]>; Andrew Dunstan <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers On Fri, Jan 09, 2026 at 05:21:45PM +0300, Nazir Bilal Yavuz wrote: > Were you able to understand why Mark's benchmark results are different > from ours? Not yet... I had some guesses, which is why I suggested the processor pinning and using a ramdisk. But we haven't tried applying all of those to my laptop, which has 3 core types, or the POWER system, which may be interesting to use a ram disk on. I'm curious though, and admittedly haven't tried looking myself yet, about how the SIMD calls might look across different processor architectures. We'll try to get that on the POWER system soon... Regards, Mark -- Mark Wong <[email protected]> EDB https://enterprisedb.com ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Speed up COPY FROM text/CSV parsing using SIMD @ 2026-01-14 00:20 Manni Wood <[email protected]> parent: Mark Wong <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Manni Wood @ 2026-01-14 00:20 UTC (permalink / raw) To: Mark Wong <[email protected]>; +Cc: Nazir Bilal Yavuz <[email protected]>; KAZAR Ayoub <[email protected]>; Nathan Bossart <[email protected]>; Andrew Dunstan <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers On Tue, Jan 13, 2026 at 1:12 PM Mark Wong <[email protected]> wrote: > On Fri, Jan 09, 2026 at 05:21:45PM +0300, Nazir Bilal Yavuz wrote: > > Were you able to understand why Mark's benchmark results are different > > from ours? > > Not yet... I had some guesses, which is why I suggested the processor > pinning > and using a ramdisk. But we haven't tried applying all of those to my > laptop, > which has 3 core types, or the POWER system, which may be interesting to > use a > ram disk on. > > I'm curious though, and admittedly haven't tried looking myself yet, about > how > the SIMD calls might look across different processor architectures. We'll > try > to get that on the POWER system soon... > > Regards, > Mark > -- > Mark Wong <[email protected]> > EDB https://enterprisedb.com > Hello! Nazir, I'm glad you are finding the benchmarks useful. I have more! :-) All of these benchmarks are all-in-RAM, because I do think that is the best way of getting closest to the theoretical best and worst case scenarios. My laptop: master: (852558b9) text, no special: 14996 text, 1/3 special: 17270 csv, no special: 18274 csv, 1/3 special: 23852 v3 text, no special: 11282 (24.7% speedup) text, 1/3 special: 15748 (8.8% speedup) <-- I don't believe this but it's what I got csv, no special: 11571 (36.6% speedup) csv, 1/3 special: 19934 (16.4% speedup) <-- I don't believe this but it's what I got v4.2 text, no special: 11139 (25.7% speedup) text, 1/3 special: 18900 (9.4% regression) csv, no special: 11490 (37.1% speedup) csv, 1/3 special: 26134 (9.5% regression) An AWS EC2 t2.2xlarge instance master: (852558b9) text, no special: 20677 text, 1/3 special: 22660 csv, no special: 24534 csv, 1/3 special: 30999 v3 text, no special: 17534 (15.2% speedup) text, 1/3 special: 22816 (0.6% regression) csv, no special: 17664 (28.0% speedup) csv, 1/3 special: 29338 (5.3% speedup) <-- I don't believe this but it's what I got v4.2 text, no special: 17459 (15.5% speedup) text, 1/3 special: 25051 (10.5% regression) csv, no special: 17574 (28.3% speedup) csv, 1/3 special: 32092 (3.5% regression) An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM processor!) master: (852558b9) text, no special: 22081 text, 1/3 special: 25100 csv, no special: 27296 csv, 1/3 special: 32344 v3 text, no special: 17724 (19.7% speedup) text, 1/3 special: 27606 (9.9% regression) <-- yikes! We would want to test this more csv, no special: 17597 (35.5% speedup) csv, 1/3 special: 32597 (0.8% regression) v4.2 text, no special: 17674 (20% speedup) text, 1/3 special: 25773 (2.6% regression) <-- this regression is less than for the v3 patch? Atypical... csv, no special: 17651 (35.3% speedup) csv, 1/3 special: 34055 (5.3% regression) Yes, I think I agree with you that the everything-in-RAM benchmarks will make the regressions more pronounced, just like the everything-in-RAM benchmarks make the improvements more pronounced. I am not sure why the CSV regression, compared to the TXT regression (even for the v3 patch which has smaller regressions than the v4.2 patch) is usually worse. I probably should look over some flame graphs and see if I can find the place where the CSV-parsing code is so much slower. The CSV regression is actually a bit frustrating (at around 5%) because the TXT regression, at less than 1% (for the v3 patch) is so much easier to bare. Here are some copy-to benchmarks for the v4 patch that applies SIMD to the copy-to code. These were all-in-RAM tests. My laptop master: (852558b9) text, no special: 2948 text, 1/3 special: 11258 csv, no special: 6245 csv, 1/3 special: 11258 v4 (copy to) text, no special: 2126 (27.9% speedup) text, 1/3 special: 12080 (7.3% regression) <-- did not see such a big regression before csv, no special: 2432 (61.0% speedup) csv, 1/3 special: 12344 (4.0% regression) <-- did not see such a big regression before An AWS EC2 t2.2xlarge instance master: (852558b9) text, no special: 4647 text, 1/3 special: 13865 csv, no special: 5421 csv, 1/3 special: 15284 v4 (copy to) text, no special: 2460 (47.0% speedup) text, 1/3 special: 14023 (1.1% regression) csv, no special: 2667 (50.7% speedup) csv, 1/3 special: 15251 (0.2% speedup) An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM processor!) master: (852558b9) text, no special: 6951 text, 1/3 special: 17857 csv, no special: 7951 csv, 1/3 special: 18504 v4 (copy to) text, no special: 3372 (51.4% speedup) text, 1/3 special: 15713 (12.0% speedup) csv, no special: 3233 (59.3% speedup) csv, 1/3 special: 1622 (12.3% speedup) Once again, the v4 patch for copy-to seems like a clearer win, though, to be fair, there were regressions when running on my laptop. (I'm starting to think servers or desktops are better than laptops for testing these things, though maybe that's my bias: it just seems like the server results are always less surprising.) Hope you all continue to find these useful... -- -- Manni Wood EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Speed up COPY FROM text/CSV parsing using SIMD @ 2026-01-17 21:24 KAZAR Ayoub <[email protected]> parent: Manni Wood <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: KAZAR Ayoub @ 2026-01-17 21:24 UTC (permalink / raw) To: Manni Wood <[email protected]>; +Cc: Mark Wong <[email protected]>; Nazir Bilal Yavuz <[email protected]>; Nathan Bossart <[email protected]>; Andrew Dunstan <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers Hello, Thank you for these benchmarks, this is helpful ! On Wed, Jan 14, 2026 at 1:20 AM Manni Wood <[email protected]> wrote: > > > Hello! > > Nazir, I'm glad you are finding the benchmarks useful. I have more! :-) > > All of these benchmarks are all-in-RAM, because I do think that is the > best way of getting closest to the theoretical best and worst case > scenarios. > > My laptop: > > master: (852558b9) > > text, no special: 14996 > text, 1/3 special: 17270 > csv, no special: 18274 > csv, 1/3 special: 23852 > > v3 > > text, no special: 11282 (24.7% speedup) > text, 1/3 special: 15748 (8.8% speedup) <-- I don't believe this but it's > what I got > csv, no special: 11571 (36.6% speedup) > csv, 1/3 special: 19934 (16.4% speedup) <-- I don't believe this but it's > what I got > > v4.2 > > text, no special: 11139 (25.7% speedup) > text, 1/3 special: 18900 (9.4% regression) > csv, no special: 11490 (37.1% speedup) > csv, 1/3 special: 26134 (9.5% regression) > > An AWS EC2 t2.2xlarge instance > > master: (852558b9) > > text, no special: 20677 > text, 1/3 special: 22660 > csv, no special: 24534 > csv, 1/3 special: 30999 > > v3 > > text, no special: 17534 (15.2% speedup) > text, 1/3 special: 22816 (0.6% regression) > csv, no special: 17664 (28.0% speedup) > csv, 1/3 special: 29338 (5.3% speedup) <-- I don't believe this but it's > what I got > > v4.2 > > text, no special: 17459 (15.5% speedup) > text, 1/3 special: 25051 (10.5% regression) > csv, no special: 17574 (28.3% speedup) > csv, 1/3 special: 32092 (3.5% regression) > > An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM > processor!) > > master: (852558b9) > > text, no special: 22081 > text, 1/3 special: 25100 > csv, no special: 27296 > csv, 1/3 special: 32344 > > v3 > > text, no special: 17724 (19.7% speedup) > text, 1/3 special: 27606 (9.9% regression) <-- yikes! We would want to > test this more > csv, no special: 17597 (35.5% speedup) > csv, 1/3 special: 32597 (0.8% regression) > > v4.2 > > text, no special: 17674 (20% speedup) > text, 1/3 special: 25773 (2.6% regression) <-- this regression is less > than for the v3 patch? Atypical... > csv, no special: 17651 (35.3% speedup) > csv, 1/3 special: 34055 (5.3% regression) > > Yes, I think I agree with you that the everything-in-RAM benchmarks will > make the regressions more pronounced, just like the everything-in-RAM > benchmarks make the improvements more pronounced. > > I am not sure why the CSV regression, compared to the TXT regression (even > for the v3 patch which has smaller regressions than the v4.2 patch) is > usually worse. I probably should look over some flame graphs and see if I > can find the place where the CSV-parsing code is so much slower. The CSV > regression is actually a bit frustrating (at around 5%) because the TXT > regression, at less than 1% (for the v3 patch) is so much easier to bare. > The only reasons that i can think of for this problem is the CSV state machine is more complex than TEXT, which might imply that for everything related to branch prediction, stalls ..etc becomes more demanding in CSV mode, i see this by previous tight micro benchmarks on CopyReadLineText, it has tiny less IPC, more branch misses, stalls and i assume instruction cache misses shouldn't be a problem since the generated code duplicates the scalar path, also the code for it isn't that large for one core instruction cache anyways (mine has 5.8KB per core). We can use perf_event_open[1] around CopyReadLine to see what's going on exactly with the counters if someone wants to confirm. > > > Here are some copy-to benchmarks for the v4 patch that applies SIMD to the > copy-to code. > > These were all-in-RAM tests. > > My laptop > > master: (852558b9) > > text, no special: 2948 > text, 1/3 special: 11258 > csv, no special: 6245 > csv, 1/3 special: 11258 > > v4 (copy to) > > text, no special: 2126 (27.9% speedup) > text, 1/3 special: 12080 (7.3% regression) <-- did not see such a big > regression before > csv, no special: 2432 (61.0% speedup) > csv, 1/3 special: 12344 (4.0% regression) <-- did not see such a big > regression before > > An AWS EC2 t2.2xlarge instance > > master: (852558b9) > > text, no special: 4647 > text, 1/3 special: 13865 > csv, no special: 5421 > csv, 1/3 special: 15284 > > v4 (copy to) > > text, no special: 2460 (47.0% speedup) > text, 1/3 special: 14023 (1.1% regression) > csv, no special: 2667 (50.7% speedup) > csv, 1/3 special: 15251 (0.2% speedup) > > An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM > processor!) > > master: (852558b9) > > text, no special: 6951 > text, 1/3 special: 17857 > csv, no special: 7951 > csv, 1/3 special: 18504 > > v4 (copy to) > > text, no special: 3372 (51.4% speedup) > text, 1/3 special: 15713 (12.0% speedup) > csv, no special: 3233 (59.3% speedup) > csv, 1/3 special: 1622 (12.3% speedup) > > Once again, the v4 patch for copy-to seems like a clearer win, though, to > be fair, there were regressions when running on my laptop. (I'm starting to > think servers or desktops are better than laptops for testing these things, > though maybe that's my bias: it just seems like the server results are > always less surprising.) > Indeed, I agree on this too. [1]https://man7.org/linux/man-pages/man2/perf_event_open.2.html Regards, Ayoub Kazar ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Speed up COPY FROM text/CSV parsing using SIMD @ 2026-01-20 20:48 Manni Wood <[email protected]> parent: KAZAR Ayoub <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Manni Wood @ 2026-01-20 20:48 UTC (permalink / raw) To: KAZAR Ayoub <[email protected]>; +Cc: Mark Wong <[email protected]>; Nazir Bilal Yavuz <[email protected]>; Nathan Bossart <[email protected]>; Andrew Dunstan <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers On Sat, Jan 17, 2026 at 3:25 PM KAZAR Ayoub <[email protected]> wrote: > Hello, > Thank you for these benchmarks, this is helpful ! > > On Wed, Jan 14, 2026 at 1:20 AM Manni Wood <[email protected]> > wrote: > >> >> >> Hello! >> >> Nazir, I'm glad you are finding the benchmarks useful. I have more! :-) >> >> All of these benchmarks are all-in-RAM, because I do think that is the >> best way of getting closest to the theoretical best and worst case >> scenarios. >> >> My laptop: >> >> master: (852558b9) >> >> text, no special: 14996 >> text, 1/3 special: 17270 >> csv, no special: 18274 >> csv, 1/3 special: 23852 >> >> v3 >> >> text, no special: 11282 (24.7% speedup) >> text, 1/3 special: 15748 (8.8% speedup) <-- I don't believe this but it's >> what I got >> csv, no special: 11571 (36.6% speedup) >> csv, 1/3 special: 19934 (16.4% speedup) <-- I don't believe this but it's >> what I got >> >> v4.2 >> >> text, no special: 11139 (25.7% speedup) >> text, 1/3 special: 18900 (9.4% regression) >> csv, no special: 11490 (37.1% speedup) >> csv, 1/3 special: 26134 (9.5% regression) >> >> An AWS EC2 t2.2xlarge instance >> >> master: (852558b9) >> >> text, no special: 20677 >> text, 1/3 special: 22660 >> csv, no special: 24534 >> csv, 1/3 special: 30999 >> >> v3 >> >> text, no special: 17534 (15.2% speedup) >> text, 1/3 special: 22816 (0.6% regression) >> csv, no special: 17664 (28.0% speedup) >> csv, 1/3 special: 29338 (5.3% speedup) <-- I don't believe this but it's >> what I got >> >> v4.2 >> >> text, no special: 17459 (15.5% speedup) >> text, 1/3 special: 25051 (10.5% regression) >> csv, no special: 17574 (28.3% speedup) >> csv, 1/3 special: 32092 (3.5% regression) >> >> An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM >> processor!) >> >> master: (852558b9) >> >> text, no special: 22081 >> text, 1/3 special: 25100 >> csv, no special: 27296 >> csv, 1/3 special: 32344 >> >> v3 >> >> text, no special: 17724 (19.7% speedup) >> text, 1/3 special: 27606 (9.9% regression) <-- yikes! We would want to >> test this more >> csv, no special: 17597 (35.5% speedup) >> csv, 1/3 special: 32597 (0.8% regression) >> >> v4.2 >> >> text, no special: 17674 (20% speedup) >> text, 1/3 special: 25773 (2.6% regression) <-- this regression is less >> than for the v3 patch? Atypical... >> csv, no special: 17651 (35.3% speedup) >> csv, 1/3 special: 34055 (5.3% regression) >> >> Yes, I think I agree with you that the everything-in-RAM benchmarks will >> make the regressions more pronounced, just like the everything-in-RAM >> benchmarks make the improvements more pronounced. >> >> I am not sure why the CSV regression, compared to the TXT regression >> (even for the v3 patch which has smaller regressions than the v4.2 patch) >> is usually worse. I probably should look over some flame graphs and see if >> I can find the place where the CSV-parsing code is so much slower. The CSV >> regression is actually a bit frustrating (at around 5%) because the TXT >> regression, at less than 1% (for the v3 patch) is so much easier to bare. >> > The only reasons that i can think of for this problem is the CSV state > machine is more complex than TEXT, which might imply that for everything > related to branch prediction, stalls ..etc becomes more demanding in CSV > mode, i see this by previous tight micro benchmarks on CopyReadLineText, it > has tiny less IPC, more branch misses, stalls and i assume instruction > cache misses shouldn't be a problem since the generated code duplicates the > scalar path, also the code for it isn't that large for one core instruction > cache anyways (mine has 5.8KB per core). > We can use perf_event_open[1] around CopyReadLine to see what's going on > exactly with the counters if someone wants to confirm. > >> >> > >> Here are some copy-to benchmarks for the v4 patch that applies SIMD to >> the copy-to code. >> >> These were all-in-RAM tests. >> >> My laptop >> >> master: (852558b9) >> >> text, no special: 2948 >> text, 1/3 special: 11258 >> csv, no special: 6245 >> csv, 1/3 special: 11258 >> >> v4 (copy to) >> >> text, no special: 2126 (27.9% speedup) >> text, 1/3 special: 12080 (7.3% regression) <-- did not see such a big >> regression before >> csv, no special: 2432 (61.0% speedup) >> csv, 1/3 special: 12344 (4.0% regression) <-- did not see such a big >> regression before >> >> An AWS EC2 t2.2xlarge instance >> >> master: (852558b9) >> >> text, no special: 4647 >> text, 1/3 special: 13865 >> csv, no special: 5421 >> csv, 1/3 special: 15284 >> >> v4 (copy to) >> >> text, no special: 2460 (47.0% speedup) >> text, 1/3 special: 14023 (1.1% regression) >> csv, no special: 2667 (50.7% speedup) >> csv, 1/3 special: 15251 (0.2% speedup) >> >> An AWS EC2 t4g.2xlarge instance (using ARM processor; first test of ARM >> processor!) >> >> master: (852558b9) >> >> text, no special: 6951 >> text, 1/3 special: 17857 >> csv, no special: 7951 >> csv, 1/3 special: 18504 >> >> v4 (copy to) >> >> text, no special: 3372 (51.4% speedup) >> text, 1/3 special: 15713 (12.0% speedup) >> csv, no special: 3233 (59.3% speedup) >> csv, 1/3 special: 1622 (12.3% speedup) >> >> Once again, the v4 patch for copy-to seems like a clearer win, though, to >> be fair, there were regressions when running on my laptop. (I'm starting to >> think servers or desktops are better than laptops for testing these things, >> though maybe that's my bias: it just seems like the server results are >> always less surprising.) >> > Indeed, I agree on this too. > > [1]https://man7.org/linux/man-pages/man2/perf_event_open.2.html > > Regards, > Ayoub Kazar > Hello, all I have more benchmarks. These benchmarks are from a Raspberry Pi 5 that I bought. It has an Arm Cortex A76 processor. (I was so impressed with the stability of the results I got on my standalone Intel tower PC that I figured I needed a standalone Arm-based machine that was not a laptop and not a VM at a cloud service provider. The run-to-run results were indeed more stable, just like with my standalone tower PC.) COPY FROM master: (852558b9) text, no special: 9111 text, 1/3 special: 10302 csv, no special: 11147 csv, 1/3 special: 13375 v3 text, no special: 7351 (19.3% speedup) text, 1/3 special: 10397 (0.9% regression) csv, no special: 7272 (34.7% speedup) csv, 1/3 special: 13472 (0.7% regression) v4.2 text, no special: 7300 (19.6% speedup) text, 1/3 special: 10537 (2.3% regression) csv, no special: 7260 (34.8% speedup) csv, 1/3 special: 13881 (3.8% regression) COPY TO master: (852558b9) text, no special: 2446 text, 1/3 special: 6988 csv, no special: 2822 csv, 1/3 special: 6967 v4 (copy to) text, no special: 1533 (37.3% speedup) text, 1/3 special: 5949 (14.8% speedup) csv, no special: 1560 (44.7% speedup) csv, 1/3 special: 6006 (13.8% speedup) I find these results particularly exciting because with the COPY FROM v3 patch, the worst-case scenarios are just under 1% regression. The v4 COPY TO patch is a win across the board. Note that I ran these benchmarks with everything in RAM disk and using the cpupower instructions that Nazir suggested. So on Arm, the v3 COPY FROM patch is almost all upside, and the v4 COPY TO patch is all upside. The same is almost true for Intel, but the CSV COPY FROM regression, even from the V3 COPY FROM patch, is about 5%. The v4.2 COPY FROM patch always performs worse than the v3 COPY FROM patch in worst-case scenarios. Does it seem reasonable to stop performance testing the v4.2 COPY FROM patch? Have we collected enough benchmark data to be confident that the v3 COPY FROM patch is the one we should be moving forward with? Hope you are all having a great day, -Manni -- -- Manni Wood EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Speed up COPY FROM text/CSV parsing using SIMD @ 2026-01-22 18:22 KAZAR Ayoub <[email protected]> parent: Manni Wood <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: KAZAR Ayoub @ 2026-01-22 18:22 UTC (permalink / raw) To: Manni Wood <[email protected]>; +Cc: Mark Wong <[email protected]>; Nazir Bilal Yavuz <[email protected]>; Nathan Bossart <[email protected]>; Andrew Dunstan <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers Hello, On Tue, Jan 20, 2026 at 9:49 PM Manni Wood <[email protected]> wrote: > Hello, all I have more benchmarks. > > These benchmarks are from a Raspberry Pi 5 that I bought. It has an Arm > Cortex A76 processor. > > (I was so impressed with the stability of the results I got on my > standalone Intel tower PC that I figured I needed a standalone Arm-based > machine that was not a laptop and not a VM at a cloud service provider. The > run-to-run results were indeed more stable, just like with my standalone > tower PC.) > > COPY FROM > > master: (852558b9) > > text, no special: 9111 > text, 1/3 special: 10302 > csv, no special: 11147 > csv, 1/3 special: 13375 > > v3 > > text, no special: 7351 (19.3% speedup) > text, 1/3 special: 10397 (0.9% regression) > csv, no special: 7272 (34.7% speedup) > csv, 1/3 special: 13472 (0.7% regression) > > v4.2 > > text, no special: 7300 (19.6% speedup) > text, 1/3 special: 10537 (2.3% regression) > csv, no special: 7260 (34.8% speedup) > csv, 1/3 special: 13881 (3.8% regression) > > COPY TO > > master: (852558b9) > > text, no special: 2446 > text, 1/3 special: 6988 > csv, no special: 2822 > csv, 1/3 special: 6967 > > v4 (copy to) > > text, no special: 1533 (37.3% speedup) > text, 1/3 special: 5949 (14.8% speedup) > csv, no special: 1560 (44.7% speedup) > csv, 1/3 special: 6006 (13.8% speedup) > > I find these results particularly exciting because with the COPY FROM v3 > patch, the worst-case scenarios are just under 1% regression. The v4 COPY > TO patch is a win across the board. > > Note that I ran these benchmarks with everything in RAM disk and using the > cpupower instructions that Nazir suggested. > > So on Arm, the v3 COPY FROM patch is almost all upside, and the v4 COPY TO > patch is all upside. The same is almost true for Intel, but the CSV COPY > FROM regression, even from the V3 COPY FROM patch, is about 5%. The v4.2 > COPY FROM patch always performs worse than the v3 COPY FROM patch in > worst-case scenarios. > > Does it seem reasonable to stop performance testing the v4.2 COPY FROM > patch? Have we collected enough benchmark data to be confident that the v3 > COPY FROM patch is the one we should be moving forward with? > For the case of v4.2 using the 1/3 specials benchmark, it will always take the decision to not use SIMD after sampling and that 3%-4% regression is the combination of the small overhead of counting special characters and 2-4 branches and its effect on the general layout, branch prediction, pipeline ..etc, while i don't think it's more complex than v3 but this is the only thing i can think of. And since it assumes uniformity of special characters between lines so yes IMHO v3 is generally better. Regards, Ayoub ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-01-22 18:22 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-18 07:57 [PATCH v7 2/3] Remove "dead" flag from catcache tuple Kyotaro Horiguchi <[email protected]> 2026-01-13 19:12 Re: Speed up COPY FROM text/CSV parsing using SIMD Mark Wong <[email protected]> 2026-01-14 00:20 ` Re: Speed up COPY FROM text/CSV parsing using SIMD Manni Wood <[email protected]> 2026-01-17 21:24 ` Re: Speed up COPY FROM text/CSV parsing using SIMD KAZAR Ayoub <[email protected]> 2026-01-20 20:48 ` Re: Speed up COPY FROM text/CSV parsing using SIMD Manni Wood <[email protected]> 2026-01-22 18:22 ` Re: Speed up COPY FROM text/CSV parsing using SIMD KAZAR Ayoub <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox