Re: Pluggable Storage - Andres's take

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Pluggable Storage - Andres's take
Дата
Msg-id CAJrrPGfS-ax=dySxD_B5Vg6sjXCSqN-9g7kmV8Oq_vsEST7uAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pluggable Storage - Andres's take  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Pluggable Storage - Andres's take  (Asim R P <apraveen@pivotal.io>)
Re: Pluggable Storage - Andres's take  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On Fri, Nov 2, 2018 at 11:17 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
On Wed, Oct 31, 2018 at 9:34 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote: 
FYI, alongside with reviewing the code changes I've ran few performance tests
(that's why I hit this issue with pgbench in the first place). In case of high
concurrecy so far I see small performance degradation in comparison with the
master branch (about 2-5% of average latency, depending on the level of
concurrency), but can't really say why exactly (perf just shows barely
noticeable overhead there and there, maybe what I see is actually a cumulative
impact).

Thanks for sharing your observation, I will also analyze and try to find out performance
bottlenecks that are causing the overhead.

I tried running the pgbench performance tests with minimal clients in my laptop and I didn't
find any performance issues, may be issue is visible only with higher clients. Even with
perf tool, I am not able to get a clear problem function. As you said, combining of all changes
leads to some overhead.

Here I attached the cumulative patches with further fixes and basic syntax regress tests also.

Regards,
Haribabu Kommi
Fujitsu Australia
Вложения

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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: BUG #15160: planner overestimates number of rows in join whenthere are more than 200 rows coming from CTE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: make installcheck-world in a clean environment