From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>,
        =?UTF-8?B?0K7RgNC40Lkg0KHQvtC60L7Qu9C+0LI=?= <funny.falcon@gmail.com>,
        Sokolov Yura <funny.falcon@postgrespro.ru>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Heikki Linnakangas <hlinnaka@iki.fi>,
        PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Subject: Re: Small improvement to compactify_tuples
In-reply-to: 
 <CAGTBQpZgs4hVmDtHg4F6MDJuAE9-U=z6d+yJzjPsZup7AZhV0Q@mail.gmail.com>
References: 
 <CAL-rCA10_Tf47iCPMLrR9DVKS0cG-we4eRU-7bxtgCPeAbrqog@mail.gmail.com>
 <CAGTBQpaq4HAtMO-WPaB5dbrLBXcm69+eZC2C51A1oy4rfO+PMg@mail.gmail.com>
 <CAL-rCA1Rk=hU_vEiX5s3_-qCV+mx6JnpsvCr5AeBh57igMvBuw@mail.gmail.com>
 <CAGTBQpa7-t41u_AkfgEWtVFDi2j6qZ2-YbnSHhN8oaGkbOJF4Q@mail.gmail.com>
 <CAL-rCA1_KLQjhyba7ow0VH9Nd6=iO8GzYSrSFVBDvEX8zeCQ_w@mail.gmail.com>
 <CAGTBQpY9RiNGheQcvhTkOqyULvZAjXbjOX1Yj_zmw+zzTg3n6Q@mail.gmail.com>
 <CAL-rCA0fcwsWcUb5H8bM8ZCBFbw4iVo-FfOzfRomS+edHeSb5A@mail.gmail.com>
 <CAGTBQpaZBjJfYGmc=RQ-mG1cWtArvoNV0gMH4qrBNkiaFFUfAQ@mail.gmail.com>
 <CAL-rCA2toMO_NwXb6N85wGJ_KRYSCxwzEEc0-hTV0Oyr86wotw@mail.gmail.com>
 <CAGTBQpbX6Pv1jLc=CjH67qkKGyuL0EwWcoorjg+UfD4LcfiZ_Q@mail.gmail.com>
 <20171107152004.axgznk3n5tkzvnnt@alap3.anarazel.de>
 <29007.1510090796@sss.pgh.pa.us>
 <CA+TgmobyDksaVkoj=VTFovcw02mMBrjsbx7F9Nvm4tXTHU6HfQ@mail.gmail.com>
 <19570.1510155199@sss.pgh.pa.us>
 <CAGTBQpZgs4hVmDtHg4F6MDJuAE9-U=z6d+yJzjPsZup7AZhV0Q@mail.gmail.com>
Comments: In-reply-to Claudio Freire <klaussfreire@gmail.com>
	message dated "Wed, 08 Nov 2017 13:29:15 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22995.1510160560.1@sss.pgh.pa.us>
Date: Wed, 08 Nov 2017 12:02:40 -0500
Message-ID: <22996.1510160560@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Claudio Freire <klaussfreire@gmail.com> writes:
> What's perhaps not clear is whether there are better ideas. Like
> rebuilding the page as Tom proposes, which doesn't seem like a bad
> idea. Bucket sort already is O(bytes), just as memcopy, only it has a
> lower constant factor (it's bytes/256 in the original patch), which
> might make copying the whole page an extra time lose against bucket
> sort in a few cases.

> Deciding that last point does need more benchmarking. That doesn't
> mean the other improvements can't be pursued in the meanwhile, right?

Well, I doubt we're going to end up committing more than one of these
ideas.  The question is which way is best.  If people are willing to
put in the work to test all of them, let's do it.

BTW, it strikes me that in considering the rebuild-the-page approach,
we should not have blinders on and just measure the speed of
PageRepairFragmentation.  Rather, we should take a look at what happens
subsequently given a physically-ordered set of tuples.  I can recall
Andres or someone moaning awhile ago about lack of locality of access in
index page searches --- maybe applying that approach while vacuuming
indexes will help?

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers