Re: Wait free LW_SHARED acquisition - v0.9

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Wait free LW_SHARED acquisition - v0.9
Дата
Msg-id 20141017181137.GE2075@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Wait free LW_SHARED acquisition - v0.9  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Wait free LW_SHARED acquisition - v0.9
Список pgsql-hackers
On 2014-10-17 17:14:16 +0530, Amit Kapila wrote:
> On Tue, Oct 14, 2014 at 11:34 AM, Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> >
> >
> > I am not sure why we are seeing difference even though running
> > on same m/c with same configuration.
> 
> I have tried many times, but I could not get the numbers you have
> posted above with HEAD, however now trying with the latest version
> [1] posted by you, everything seems to be fine at this workload.
> The data at higher client count is as below:

I'll try to reproduce it next week. But I don't think it matters all
that much. Personally so far the performance numbers don't seem to
indicate much reason to wait any further. We sure improve further, but I
don't see much reason to wait because of that.

>   HEAD – commit 494affb
> 
>  Shared_buffers=8GB; Scale Factor = 3000
> 
>  Client Count/No. Of Runs (tps) 64 128  Run-1 271799 247777  Run-2 274341
> 245207  Run-3 275019 252258
> 
> 
> 
> 
> 
>  HEAD – commit 494affb + wait free lw_shared_v2
> 
>  Shared_buffers=8GB; Scale Factor = 3000
> 
>  Client Count/No. Of Runs (tps) 64 128  Run-1 286209 274922  Run-2 289101
> 274495  Run-3 289639 273633

So here the results with LW_SHARED were consistently better, right? You
saw performance degradations here earlier?

> So I am planning to proceed further with the review/test of your
> latest patch.

> According to me, below things are left from myside:
> a. do some basic tpc-b tests with patch
> b. re-review latest version posted by you

Cool!

> I know that you have posted optimization into StrategyGetBuffer() in
> this thread, however I feel we can evaluate it separately unless you
> are of opinion that both the patches should go together.
> 
> [1]
> http://www.postgresql.org/message-id/20141010111027.GC6670@alap3.anarazel.de

No, I don't think they should go together - I wrote that patch because
it was the bottleneck in the possibly regressing test and I wanted to
see the full effect. Although I do think we should apply it ;)

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Vitesse DB call for testing
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Vitesse DB call for testing