From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Andres Freund <andres@anarazel.de>,
        Claudio Freire <klaussfreire@gmail.com>,
        =?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: 
 <CAH2-Wzm756SNypEoZH1RxypkTu23DMO0wBhN3ft3E6pmOEi+5A@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>
 <CAH2-Wzm756SNypEoZH1RxypkTu23DMO0wBhN3ft3E6pmOEi+5A@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Tue, 07 Nov 2017 14:11:07 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10933.1510094200.1@sss.pgh.pa.us>
Date: Tue, 07 Nov 2017 17:36:40 -0500
Message-ID: <10934.1510094200@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Peter Geoghegan <pg@bowt.ie> writes:
> My point is only that it's worth considering that this factor affects
> how representative your sympathetic case is. It's not clear how many
> PageIndexMultiDelete() calls are from opportunistic calls to
> _bt_vacuum_one_page(), how important that subset of calls is, and so
> on. Maybe it doesn't matter at all.

According to the perf measurements I took earlier, essentially all the
compactify_tuple calls in this test case are from PageRepairFragmentation
(from heap_page_prune), not PageIndexMultiDelete.

I'd be the first to agree that I doubt that test case is really
representative.  I'd been whacking around Yura's original case to
try to get PageRepairFragmentation's runtime up to some measurable
fraction of the total, and while I eventually succeeded, I'm not
sure that too many real workloads will look like that.  However,
if we can make it smaller as well as faster, that seems like a win
even if it's not a measurable fraction of most workloads.

			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