Re: Wait free LW_SHARED acquisition - v0.9

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Wait free LW_SHARED acquisition - v0.9
Date: 2014-10-17 18:11:37
Message-ID: 20141017181137.GE2075@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-10-17 18:13:00 Re: Vitesse DB call for testing
Previous Message Feng Tian 2014-10-17 18:08:48 Fwd: Vitesse DB call for testing