Re: BUG #15609: synchronous_commit=off insert performance regression with secondary indexes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: "Saul, Jean Paolo" <paolo(dot)saul(at)verizonconnect(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15609: synchronous_commit=off insert performance regression with secondary indexes
Date: 2019-01-30 01:36:14
Message-ID: CAH2-WznxL5vK9vwtXEPS28D5mjUi374665=Jg3p1ObC1MJw1tQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jan 29, 2019 at 2:05 PM Saul, Jean Paolo
<paolo(dot)saul(at)verizonconnect(dot)com> wrote:
> Before each test run, I drop and recreate the table and indexes.

What happens if you don't create bool_idx, or replace it with another
index on some other column? I notice that you didn't show any case
that doesn't have this index, except for the PK-only case, which is
actually faster. I surmise that that's the common factor in all of the
test cases where you have observed a regression. It would be nice to
confirm or disprove this theory.

The nbtree code is known to deal poorly with low cardinality indexes
[1], something I'm currently working to address. Are you comparing
installations that are on the same hardware and operating system?

[1] https://postgr.es/m/CAH2-Wzmf0fvVhU+SSZpGW4Qe9t--j_DmXdX3it5JcdB8FF2EsA@mail.gmail.com
--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Saul, Jean Paolo 2019-01-30 04:26:49 Re: BUG #15609: synchronous_commit=off insert performance regression with secondary indexes
Previous Message Saul, Jean Paolo 2019-01-30 00:59:20 Re: BUG #15609: synchronous_commit=off insert performance regression with secondary indexes