pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>
Cc: Claudio Freire <klaussfreire@gmail.com>
Cc: Юрий Соколов <funny.falcon@gmail.com>
Cc: Sokolov Yura <funny.falcon@postgrespro.ru>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Subject: Re: Small improvement to compactify_tuples
Date: Tue, 07 Nov 2017 17:36:40 -0500
Message-ID: <10934.1510094200@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (60+ messages)  latest in thread

Message-ID: <10934.1510094200@sss.pgh.pa.us>
Permalink:  ../10934.1510094200@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10934.1510094200@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, andres@anarazel.de, klaussfreire@gmail.com, funny.falcon@gmail.com, funny.falcon@postgrespro.ru, alvherre@2ndquadrant.com, hlinnaka@iki.fi
  Subject: Re: Small improvement to compactify_tuples
  In-Reply-To: <10934.1510094200@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox