On 20 February 2018 at 23:10, David Rowley <david.row...@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
bsearch_getmissingattr.patch
Description: Binary data