Re: BUG #15609: synchronous_commit=off insert performance regressionwith secondary indexes - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: BUG #15609: synchronous_commit=off insert performance regressionwith secondary indexes
Date
Msg-id CAH2-Wznf1uVBguutwrvR+6NcXTKYhagvNOY3-dg9dzcYiu_vKw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15609: synchronous_commit=off insert performance regressionwith secondary indexes  ("Saul, Jean Paolo" <paolo.saul@verizonconnect.com>)
Responses Re: BUG #15609: synchronous_commit=off insert performance regressionwith secondary indexes  ("Saul, Jean Paolo" <paolo.saul@verizonconnect.com>)
List pgsql-bugs
On Sun, Feb 10, 2019 at 3:05 PM Saul, Jean Paolo
<paolo.saul@verizonconnect.com> wrote:
> Can anyone please shed some light as to why this works?
> The only thing I could think of is a locking issue with the leaf nodes.

I describe why in the original thread about the problem and my
approach, though it's very low level stuff. See:

https://www.postgresql.org/message-id/flat/CAH2-Wzmf0fvVhU+SSZpGW4Qe9t--j_DmXdX3it5JcdB8FF2EsA@mail.gmail.com

> How much testing is required for this to be considered a proper bug?

You haven't really demonstrated a substantial regression across
versions (17361.186258 tps on v11, down from 20137.416962 tps on 9.5),
which is the only way that this could get classified as a bug. It's a
*far* smaller difference than the difference that you show between
otherwise-similar high cardinality and low cardinality indexes. In
general, I'm confused about why you're concerned about v11 in
particular here.

-- 
Peter Geoghegan


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15628: Error while installing postgreSQL
Next
From: David Rowley
Date:
Subject: Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name