On 20 February 2018 at 23:10, David Rowley <david.rowley@2ndquadrant.com> wrote:
> Nevertheless, it would be interesting to see how much a bsearch in
> getmissingattr would help Tomas' case. Though, perhaps you're happy
> enough with the performance already.
I thought I'd give this a quick test using the attached (incomplete) patch.
My findings made me realise that Tomas' case actually exploited a best
case for the patch.
Tomas' query.sql is performing a sum(c1000), which is the final column
in the table. No doubt he's done this since it's the typical thing to
do to get a worst case for tuple deforming, but he might not have
realised it was the best case for your patch due to the way you're
performing the for loop in getmissingattr starting with the final
missing value first.
I noticed this when I tested the mockup bsearch code. I was surprised
to see that it actually slowed performance a little with the
sum(c1000) case.
The entire results for those using:
pgbench -n -T 60 -j 1 -c 1 -f query.sql postgres
is:
Using: select sum(c1000) from t;
v11 + bsearch + create.sql: tps = 1479.267518
v11 + bsearch + create-alter.sql: tps = 1366.885968
v11 + create.sql: tps = 1544.378091
v11 + create-alter.sql: tps = 1416.608320
(both the create.sql results should be about the same here since
they're not really exercising any new code.)
Notice that the bsearch version is slightly slower, 1366 tps vs 1416.
If I use sum(c10) instead, I get.
Using: select sum(c10) from t;
v11 + bsearch + create-alter.sql: tps = 1445.940061
v11 + bsearch + create.sql: tps = 3320.102543
v11 + create.sql: tps = 3330.131437
v11 + create-alter.sql: tps = 1398.635251
The bsearch here does help recover some performance, but it's a small
improvement on what is quite a big drop from the create.sql case.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services