Re: Make tuple deformation faster
Victor Yegorov <vyegorov@gmail.com>
From: Victor Yegorov <vyegorov@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-11-29T13:54:38Z
Lists: pgsql-hackers
Attachments
- deform_test.sh.txt (text/plain)
- pic-1.jpeg (image/jpeg)
- pic-2.jpeg (image/jpeg)
- pic-3.jpeg (image/jpeg)
- 20241129-i7-48-deform-master-5.txt (text/plain)
- 20241127-M3-48-deform-master-5.txt (text/plain)
- 20241129-i7-48-deform-patched-5.txt (text/plain)
- 20241127-M3-48-deform-patched-5.txt (text/plain)
ср, 9 окт. 2024 г. в 17:00, David Rowley <dgrowleyml@gmail.com>: > I'm not sure what to do about this part. I did quite a bit of staring > at the attached benchmark results. Using gcc13.2 on my Zen2 machine, > the 0005 patch is quite a bit faster (138 tps vs 127 tps) than with > just 0004 and both versions use an "add" instruction to bump to the > next CompactAttribute element. So, with that CPU, maybe it's just > faster from getting rid of the bitwise-AND code to extract the > booleans. > Hey. I've been testing this patch for the last week, I have M3 and i7 based MBP around. I've modified deform_test.sh to have an equal number of columns for all cases, so that table size is always the same, and also increased the extra count to 48. Attached. i7 shows nice and stable results, there's a clear win from this patch (see pic-1). M3 behaves very strangely, I cannot explain the first birst and the following drop in TPS. But it's reproducible. Also, making tests do some IO yields better TPS up to 20 extra columns (see pic-2). I tend to just ignore M3 results, as it's smth to do with the HW, not the patch. Combined results for in-memory sets are on pic-3. Construct sizeof(FormData_pg_attribute) * (src)->natts is used in 7 places (in various forms), I thought it might be good to use a macro here, say TupleArraySize(natts). In v4-0002-Introduce-CompactAttribute-array-in-TupleDesc.patch +#define COMPACT_ATTR_IS_PACKABLE(att) \ +> ((att)->attlen == -1 && att->attispackable) Seems second att needs parenthesis around it. Although I haven't seen 30% speedup, I find this change very good to have. -- Victor Yegorov
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix possible Assert failure in verify_compact_attribute()
- 33b06a20016d 18.0 landed
-
Speedup tuple deformation with additional function inlining
- 58a359e585d0 18.0 landed
-
Fix race condition in TupleDescCompactAttr assert code
- 6f3820f37aba 18.0 landed
-
Optimize alignment calculations in tuple form/deform
- db448ce5ad36 18.0 landed
-
Remove pg_attribute.attcacheoff column
- 02a8d0c45253 18.0 landed
-
Introduce CompactAttribute array in TupleDesc, take 2
- 5983a4cffc31 18.0 landed
-
Introduce CompactAttribute array in TupleDesc
- d28dff3f6cd6 18.0 landed
-
Use TupleDescAttr macro consistently
- 65b71dec2d57 18.0 landed