<div dir="auto">Hi,</div><div dir="auto"><br></div><div dir="auto">Thanks for the fast response.</div><div dir="auto"><br></div><div dir="auto">Do you think that if i’ll used memcached instead of shmem the performance would be better?</div><div dir="auto">Probably memcached using a better locking mechanism.</div><div dir="auto"><br></div><div dir="auto">Thanks, </div><div dir="auto"><br></div><div dir="auto">Avi.</div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 13 Sep 2022 at 7:18 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">> Hi,<br>
> <br>
> I ran 100 connections concurrently with pooling and query cache enabled,<br>
> and I saw a poor performance which indicting  on a very big query waits.<br>
> <br>
> I found in code that there is a locking mechanism when fetching from shmem.<br>
> <br>
> Could you please share why you make a critical section when pgpool trying<br>
> to read from cache?<br>
<br>
Because concurrent modifications to the tables could delete query<br>
cache, which will confuse process that are reading the cache.<br>
<br>
Ideally the process reading query cache should only grab a shared<br>
lock, which will not block other reading process. Unfortunately we do<br>
not have shared lock facility (we only have exclusive lock).<br>
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS LLC<br>
English: <a href="http://www.sraoss.co.jp/index_en/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en/</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div></div>