Re: Move PinBuffer and UnpinBuffer to atomics
| От | Amit Kapila |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | CAA4eK1+ZW39LmP_AA0uH+oJ_=FtQR3WQey02RqrzHD6VoETAHQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Move PinBuffer and UnpinBuffer to atomics
|
| Список | pgsql-hackers |
On Sun, Feb 28, 2016 at 9:05 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
>
> On Sat, Feb 27, 2016 at 5:14 AM, Andres Freund <andres@anarazel.de> wrote:
>>
>> > > > >> ./pgbench -j$ -c$ -T300 -M prepared -S postgres
>> > > > >>
>> > > > >> Client Base Patch
>> > > > >> 1 17169 16454
>> > > > >> 8 108547 105559
>> > > > >> 32 241619 262818
>> > > > >> 64 206868 233606
>> > > > >> 128 137084 217013
>> > >
>> > > So, there's a small regression on low client counts. That's worth
>> > > addressing.
>> > >
>> >
>> > Interesting. I'll try to reproduce it.
>>
>> Any progress here?
>
>
> In Multi socket machine with 8 sockets and 64 cores, I have seen more regression compared to my previous run in power8 with 2 socket, currently I tested Read only workload for 5 mins Run, When I get time, I will run for longer time and confirm again.
>
>
>
> On Sat, Feb 27, 2016 at 5:14 AM, Andres Freund <andres@anarazel.de> wrote:
>>
>> > > > >> ./pgbench -j$ -c$ -T300 -M prepared -S postgres
>> > > > >>
>> > > > >> Client Base Patch
>> > > > >> 1 17169 16454
>> > > > >> 8 108547 105559
>> > > > >> 32 241619 262818
>> > > > >> 64 206868 233606
>> > > > >> 128 137084 217013
>> > >
>> > > So, there's a small regression on low client counts. That's worth
>> > > addressing.
>> > >
>> >
>> > Interesting. I'll try to reproduce it.
>>
>> Any progress here?
>
>
> In Multi socket machine with 8 sockets and 64 cores, I have seen more regression compared to my previous run in power8 with 2 socket, currently I tested Read only workload for 5 mins Run, When I get time, I will run for longer time and confirm again.
>
Have you tried by reverting the commits 6150a1b0 and ac1d794, which I think effects read-only performance and sometimes create variation in TPS across different runs, here second might have less impact, but first one could impact performance? Is it possible for you to get perf data with and without patch and share with others?
В списке pgsql-hackers по дате отправления: