Re: [HACKERS] Small improvement to compactify_tuples

Юрий Соколов <funny.falcon@gmail.com>

From: Yura Sokolov <funny.falcon@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael.paquier@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, Claudio Freire <klaussfreire@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Sokolov Yura <funny.falcon@postgrespro.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-03-04T09:57:45Z
Lists: pgsql-hackers
01.03.2018 22:22, Andres Freund пишет:
> Hi,
> 
> On 2018-02-25 21:39:46 +0300, Yura Sokolov wrote:
>>> If that's the case then does it really make sense to make this change..?
>>
>> I don't think it is really necessary to implement generic version
>> through templated.
> 
> Why?

It is better to replace use of generic version with templated in
appropriate places.
Generic version uses variable size of element. It will be difficult to
describe through template.

> 
>> Updated numbers are (same benchmark on same notebook, but with new
>> master, new ubuntu and later patch version) (average among 6 runs):
>>
>> master               - 16135tps
>> with templated qsort - 16199tps
>> with bucket sort     - 16956tps
>>
>> Difference is still measurable, but less significant. I don't know why.
>>
>> Rebased version of first patch (qsorted tamplate) is in atttach.
> 
> Hm, that's a bit underwhelming. It's nice to deduplicate, but 16135tps
> -> 16199tps is barely statistically significant?

I mean bucket sort is measurably faster than both generic and templated
sort (16956 vs 16199 and 16135). So initial goal remains: to add bucket
sort in this place.

BTW, I have small change to templated version that improves sorting of
random tuples a bit (1-1.5%). Will post it a bit later with test.

> - Andres
> 

With regards,
Yura.

Commits

  1. Avoid looping through line pointers twice in PageRepairFragmentation().

  2. Reduce pinning and buffer content locking for btree scans.

  3. Speed up in-memory tuplesorting.