Re: Faster inserts with mostly-monotonically increasing values

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>
Subject: Re: Faster inserts with mostly-monotonically increasing values
Date: 2018-03-22 01:52:39
Message-ID: CAGTBQpZNraiPg52e_7z7CKx3J_riYiyTvC+=nnYhkE7FjoqAfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 19, 2018 at 12:06 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee
> <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>>
>>
>> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire <klaussfreire(at)gmail(dot)com>
>> wrote:
>>>
>>>
>>>
>>> I applied the attached patches on top of your patch, so it would be
>>> nice to see if you can give it a try in your test hardware to see
>>> whether it helps.
>>
>>
>> I can confirm that I no longer see any regression at 8 or even 16 clients.
>> In fact, the patched version consistent do better than master even at higher
>> number of clients.
>>
>> The only thing I am a bit puzzled is that I am no longer able to reproduce
>> the 40-50% gains that I'd earlier observed with a single client. I now get
>> 20-25% with smaller number of client and 10-15% with larger number of
>> clients. I haven't been able to establish why it's happening, but since it's
>> a different AWS instance (though of the same type), I am inclined to blame
>> it on that for now.
>
> Your original patch also skipped the check for serializable conflicts.
>
> *IF* that was correct, it probably further reduced contention. I'm not
> entirely sure if skipping that check is correct, but if it is, you can
> still accomplish this checking whether the new key is beyond the
> current rightmost key, and setting a flag so that check is later
> skipped.
>
> But there are lots of complex interactions in that code and I'm no
> expert there, I'd prefer if someone more knowledgeable could confirm
> whether it's safe to skip that check or not. Or leave it just in case.

If you're not planning on making any further changes, would you mind
posting a coalesced patch?

Notice that I removed the last offset thing only halfway, so it would
need some cleanup.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-22 02:07:30 Re: [HACKERS] taking stdbool.h into use
Previous Message Michael Paquier 2018-03-22 01:49:57 Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two