From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Date: Thu, 4 Apr 2019 21:04:49 -0700
Message-ID: <20190405040449.5yltddxmlxombova@alap3.anarazel.de> (raw)
In-Reply-To: <959.1554436678@sss.pgh.pa.us>
References: <20190404214520.7rfufsubxekodypr@alap3.anarazel.de>
<20190405030604.GA3360@alvherre.pgsql>
<20190405033537.vklegbflesm2c7m3@alap3.anarazel.de>
<959.1554436678@sss.pgh.pa.us>
Hi,
On 2019-04-04 23:57:58 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I think the right approach would be to do all of this in heap_insert and
> > heap_multi_insert. Whenever starting to work on a page, if INSERT_FROZEN
> > is specified, remember whether it is either currently empty, or is
> > already marked as all-visible. If previously empty, mark it as all
> > visible at the end. If already all visible, there's no need to change
> > that. If not yet all-visible, no need to do anything, since it can't
> > have been inserted with COPY FREEZE. Do you see any problem doing it
> > that way?
>
> Do we want to add overhead to these hot-spot routines for this purpose?
For heap_multi_insert I can't see it being a problem - it's only used
from copy.c, and the cost should be "smeared" over many tuples. I'd
assume that compared with locking a page, WAL logging, etc, it'd not
even meaningfully show up for heap_insert. Especially because we already
have codepaths for options & HEAP_INSERT_FROZEN in
heap_prepare_insert(), and I'd assume those could be combined.
I think we should measure it, but I don't think that one or two
additional, very well predictd, branches are going to be measurable in
in those routines.
The patch, as implemented, has modifications in
RelationGetBufferForTuple(), that seems like they'd be more expensive.
Greetings,
Andres Freund
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: andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, pavan.deolasee@gmail.com, sawada.mshk@gmail.com, jeff.janes@gmail.com, simon@2ndquadrant.com, tomas.vondra@2ndquadrant.com
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
In-Reply-To: <20190405040449.5yltddxmlxombova@alap3.anarazel.de>
* 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