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

help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Date: Tue, 17 Dec 2019 16:58:25 -0500
Message-ID: <20191217215825.GA30116@momjian.us> (raw)
In-Reply-To: <CAH2-WzmqHsBW6t3TwDRygbzgMJFtukNwNcX9B+w_OrYXbftaPQ@mail.gmail.com>
References: <cf36affc-94b4-9331-0886-21b7d1d08a3c@postgrespro.ru>
	<CAH2-Wz=1FaPa2TroKYxpG7mqUJrssOfmNQOPW+vTVmG4vyXD7Q@mail.gmail.com>
	<f5069d7e-91e6-635b-5bfe-dce4e18714e2@postgrespro.ru>
	<CAH2-WzmkUseObezytp_1RPoZ==TbOj6gvc_DuTsVPbCM3Wb05Q@mail.gmail.com>
	<CAH2-Wzmww9kM99iK42nQmXONg564DPseuUDy_mSAi3OeaxU07A@mail.gmail.com>
	<CAH2-WznUHDAqUwUMya_KCJ6rNBuG3XZfU-rpyUM-LwO_BUhS2g@mail.gmail.com>
	<CAH2-Wzna4A3ZCdq2F+rqCZk9kX9ubPWbsPs2QYg-EtzQ7HU0Ng@mail.gmail.com>
	<CAH2-Wz=_XUu4j=vqGLmU=Re=caPy49yG4kwvyaeQiWKug4djKw@mail.gmail.com>
	<CAH2-WzkFrQ3m5o-nPzgo0Q1_yJjyPyRc77giCzN3fyMaQXk=8g@mail.gmail.com>
	<CAH2-WzmqHsBW6t3TwDRygbzgMJFtukNwNcX9B+w_OrYXbftaPQ@mail.gmail.com>

On Thu, Dec 12, 2019 at 06:21:20PM -0800, Peter Geoghegan wrote:
> On Tue, Dec 3, 2019 at 12:13 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > The new criteria/heuristic for unique indexes is very simple: If a
> > unique index has an existing item that is a duplicate on the incoming
> > item at the point that we might have to split the page, then apply
> > deduplication. Otherwise (when the incoming item has no duplicates),
> > don't apply deduplication at all -- just accept that we'll have to
> > split the page. We already cache the bounds of our initial binary
> > search in insert state, so we can reuse that information within
> > _bt_findinsertloc() when considering deduplication in unique indexes.
> 
> Attached is v26, which adds this new criteria/heuristic for unique
> indexes. We now seem to consistently get good results with unique
> indexes.

In the past we tried to increase the number of cases where HOT updates
can happen but were unable to.  Would this help with non-HOT updates? 
Do we have any benchmarks where non-HOT updates cause slowdowns that we
can test on this?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +





view thread (145+ messages)  latest in thread

Message-ID: <20191217215825.GA30116@momjian.us>
Permalink:  ../20191217215825.GA30116@momjian.us/
Also on:    postgresql.org/message-id/20191217215825.GA30116@momjian.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: bruce@momjian.us, pg@bowt.ie, a.lubennikova@postgrespro.ru, pgsql-hackers@lists.postgresql.org
  Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
  In-Reply-To: <20191217215825.GA30116@momjian.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