ср, 9 окт. 2024 г. в 17:00, David Rowley <dgrowleyml(at)gmail(dot)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
