Re: [HACKERS] Small improvement to compactify_tuples

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Юрий Соколов <funny.falcon@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>, 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-01-23T03:34:29Z
Lists: pgsql-hackers
Greetings,

* Юрий Соколов (funny.falcon@gmail.com) wrote:
> On Wed, Nov 29, 2017 at 8:00 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> > On Tue, Nov 28, 2017 at 2:41 PM, Andres Freund <andres@anarazel.de> wrote:
> >> Maybe it's a stupid question. But would we still want to have this after
> >> the change? These should be just specializations of the template version
> >> imo.
> 
> "generic" version operates on bytes, and it will be a bit hard to combine
> it with
> templated version. Not impossible, but it will look ugly.

If that's the case then does it really make sense to make this change..?

> In attach fixed qsort_template version.
> And version for compactify_tuples with bucket_sort and templated qsort.

While having the patch is handy, I'm not seeing any performance numbers
on this version, and I imagine others watching this thread are also
wondering about things like a test run that just uses the specialized
qsort_itemIds() without the bucketsort.

Are you planning to post some updated numbers and/or an updated test
case that hopefully shows best/worst case with this change?  Would be
good to get that on a couple of platforms too, if possible, since we've
seen that the original benchmarks weren't able to be consistently
repeated across different platforms.  Without someone doing that
leg-work, this doesn't seem like it'll be moving forward.

Marking as Waiting on Author.

Thanks!

Stephen

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.