Re: Pluggable Storage - Andres's take - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Pluggable Storage - Andres's take
Date
Msg-id CAJrrPGfS-ax=dySxD_B5Vg6sjXCSqN-9g7kmV8Oq_vsEST7uAw@mail.gmail.com
Whole thread Raw
In response to Re: Pluggable Storage - Andres's take  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Pluggable Storage - Andres's take
Re: Pluggable Storage - Andres's take
List 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
Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: BUG #15160: planner overestimates number of rows in join whenthere are more than 200 rows coming from CTE
Next
From: Tom Lane
Date:
Subject: Re: make installcheck-world in a clean environment