On 30 June 2018 at 05:40, David Rowley <david.row...@2ndquadrant.com> wrote: > I think your idea > to reduce the loops in test 6 from 2000 down to 1001 should be worth > it. I'll try the idea out next week.
The attached changes things to use your way of picking up the search for the next column at the column after the last match was found. I don't think performance will have changed much from the last version, but here are the performance results (in tps) from my laptop this time. fsync=off. Test Unpatched Patched Gain Test 1 873.837 912.981 104.48% Test 2 213.004 895.268 420.31% Test 3 224.810 887.099 394.60% Test 4 1177.533 1107.767 94.08% Test 5 97.707 402.258 411.70% Test 6 72.025 360.702 500.80% Tests are all the same as the tests done in the initial email on this thread. Tests 1 and 4 are non-partitioned tests. Any variance there should just be noise. No code was changed in either of those tests. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
v3-0001-Improve-performance-of-tuple-conversion-map-gener.patch
Description: Binary data
