Re: Locking B-tree leafs immediately in exclusive mode

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Locking B-tree leafs immediately in exclusive mode
Дата
Msg-id CAPpHfdtPzqJ3k8gpZ4JVHAuKZyhQv1=tUiVBF7skDAnsO=OrsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Locking B-tree leafs immediately in exclusive mode  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Locking B-tree leafs immediately in exclusive mode  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Mon, Jul 9, 2018 at 8:18 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Jul 9, 2018 at 9:43 AM, Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
> > In this case it also looks like we observed 1% regression.  Despite 1%
> > may seem to be very small, I think we should clarify whether it really
> > exists.  I have at least two hypothesis about this.
> >
> > 1) There is no real regression, observed difference of TPS is less
> > than error of measurements.  In order to check that we need to retry
> > the experiment multiple times.  Also, if you run benchmark on master
> > before patched version (or vice versa) you should also try to swap the
> > order to make sure there is no influence of the order of benchmarks.
> > 2) If we consider relation between TPS and number of clients, TPS is
> > typically growing with increasing number of clients until reach some
> > saturation value.  After the saturation value, there is some
> > degradation of TPS.  If patch makes some latency lower, that my cause
> > saturation to happen earlier.  In order to check that, we need run
> > benchmarks with various number of clients and draw a graph: TPS
> > depending on clients.
> >
> > So, may I ask you to make more experiments in order to clarify the
> > observed regression?
>
> It would be nice to actually see script_duplicated.sql. I don't know
> exactly what the test case was.
>
> Here is my wild guess: You may end up moving right more often within
> _bt_findinsertloc(), which is actually worse than moving right within
> _bt_moveright(), even when you _bt_moveright() in exclusive mode.
> _bt_findinsertloc() couples/crabs exclusive buffer locks because the
> unique case requires it, even when we're not inserting into a unique
> index. Whereas _bt_moveright() holds at most one buffer lock at a
> time.

I'm sorry, but I didn't understand this guess.  I agree that moving
right within _bt_findinsertloc() might be worse than moving right
within _bt_moveright().  But why should it happen more often, if both
with and without patch that happens only after _bt_moveright() in
exclusive mode (with patch _bt_search() calls _bt_moveright() in
exclusive mode)?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: WAL prefetch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Failure assertion in GROUPS mode of window function in current HEAD