On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee <florisvan...@optiver.com> wrote: > Minor conflict with that patch indeed. Attached is rebased version. I'm > running some tests now - will post the results here when finished.
Thanks. We're going to have to go back to my original approach to inlining. At least, it seemed to be necessary to do that to get any benefit from the patch on my comparatively modest workstation (using a similar pgbench SELECT benchmark to the one that you ran). Tom also had a concern about the portability of inlining without using "static inline" -- that is another reason to avoid the approach to inlining taken by v3 + v4. It's possible (though not very likely) that performance has been impacted by the deduplication patch (commit 0d861bbb), since it updated the definition of BTreeTupleGetNAtts() itself. Attached is v5, which inlines in a targeted fashion, pretty much in the same way as the earliest version. This is the same as v4 in every other way. Perhaps you can test this. -- Peter Geoghegan
v5-0001-Avoid-pipeline-stall-in-_bt_compare.patch
Description: Binary data
v5-0002-Inline-_bt_compare.patch
Description: Binary data
