Re: Faster inserts with mostly-monotonically increasing values
От | Claudio Freire |
---|---|
Тема | Re: Faster inserts with mostly-monotonically increasing values |
Дата | |
Msg-id | CAGTBQpZNraiPg52e_7z7CKx3J_riYiyTvC+=nnYhkE7FjoqAfw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Faster inserts with mostly-monotonically increasing values (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: Faster inserts with mostly-monotonically increasing values
|
Список | pgsql-hackers |
On Mon, Mar 19, 2018 at 12:06 PM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee > <pavan.deolasee@gmail.com> wrote: >> >> >> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire <klaussfreire@gmail.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.
В списке pgsql-hackers по дате отправления: