pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
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: Wed, 08 Nov 2017 12:02:40 -0500
Message-ID: <22996.1510160560@sss.pgh.pa.us> (raw )
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 >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
view thread (60+ messages) latest in thread
Message-ID: <22996.1510160560@sss.pgh.pa.us>
Permalink: ../22996.1510160560@sss.pgh.pa.us/
Also on: postgresql.org/message-id/22996.1510160560@sss.pgh.pa.us
copy link · copy postgr.es
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, klaussfreire@gmail.com, robertmhaas@gmail.com, andres@anarazel.de, funny.falcon@gmail.com, funny.falcon@postgrespro.ru, alvherre@2ndquadrant.com, hlinnaka@iki.fi
Subject: Re: Small improvement to compactify_tuples
In-Reply-To: <22996.1510160560@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