[pgpool-general: 8409] Re: Query cache in shared memory bed performance

Avi Raboah avi.raboah at gmail.com
Fri Sep 16 00:52:16 JST 2022


That’s great i’ll try this.

Thanks a lot.

On Thu, 15 Sep 2022 at 9:56 Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > Ideally the process reading query cache should only grab a shared
> > lock, which will not block other reading process. Unfortunately we do
> > not have shared lock facility (we only have exclusive lock).
>
> I have created a proof of concept patch to implement the share lock
> using flock(2). Attached is a graph showing the benchmark result. The
> Y axis is the number of queries executed within 1 second. The X axis
> is the number of concurrent session.
>
> As you can see new implementation (enable query cache (flock,
> exclusive lock for update), green line) outperforms existing
> implementation using exclusive lock only (red line) as number of
> concurrent users increases. Note that this is somewhat extreme case
> because the cache hit ratio is 100% (i.e. exactly same query is used
> during the benchmark). So the difference will not be that big in the
> wild.
>
> The actual query used was:
> SELECT repeat('abcdefg', 500);
>
> The blue line is the case when query cache is disabled just for
> reference.
>
> The benchmark was performed on a Ubuntu 20 box with 16GB mem, 6 physical
> cores, 12 vcores.
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20220915/ab09116b/attachment-0001.htm>


More information about the pgpool-general mailing list