<div dir="auto">Hi,</div><div dir="auto">I am not sure I understood what you mean when you mentioned “close message”</div><div dir="auto"><br></div><div dir="auto">But i’ll try to ask you in a different way.</div><div dir="auto"><br></div><div dir="auto">Let look on the following example:</div><div dir="auto"><br></div><div dir="auto">1. Select * from users where id = $1; using extended query. —> miss</div><div dir="auto"><br></div><div dir="auto">2. Now in case i’ll run the same query i’ll get it back from cache.</div><div dir="auto"><br></div><div dir="auto">So I am understanding why the parse message should be pass to the backend and not read the result from cache due to that Parse message didn’t contains the query params. That’s make sense.</div><div dir="auto"><br></div><div dir="auto">But in Bind message the packet already contains the query params. So why you can’t read the result from cache here and we need to wait to the execute message?</div><div dir="auto"><br></div><div dir="auto">One more question is why we need to send the bind message anyway to the backend in case we have already the result of the execute message in cache?</div><div dir="auto"><br></div><div dir="auto">I am asking the above questions because I am looking in the rds performance insights.</div><div dir="auto">And I can see that in case I am sending a lot of queries concurrently when I have cache enabled I can see a very big wait because of a lot of connections in idle ClientRead wait event.</div><div dir="auto"><br></div><div dir="auto">And I am asking myself why the db needs to know about queries we already have in cache?</div><div dir="auto"><br></div><div dir="auto">Hope it was clear.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thanks a lot,</div><div dir="auto"><br></div><div dir="auto">Avi</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 14 Sep 2022 at 2:42 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>
> In case query already cached, why in extended query mode the db knows about<br>
> that query?<br>
> Because in that case pgpool should return the result from the cache in<br>
> order to save db resources.<br>
> But I found that although we have the query in cache pgpool still send<br>
> parse and bind request to the db.<br>
> <br>
> Please share your thoughts 🙏<br>
<br>
Yes, Pgpool-II only caches the result of execute message. The main<br>
reason is, to not return stale cache.  After receiving a close message<br>
for the statement or the portal that is bound to the execute message,<br>
the cache for the execute message should not be returned. When<br>
Pgpool-II receives close messages, they remove the internal record of<br>
previpusly received statement or portal. When an execute message<br>
arrives, Pgpool-II checks whether the record for the execute message<br>
exists. If does not, the request fails. This strategy is simple but<br>
works well.<br>
<br>
I think the saving by caching parse message is not small for<br>
especially complex queries. But in this case users already reuse the<br>
prepared statement anyway.<br>
<br>
I think the saving of bind message is usually small because it does<br>
not involve planning in most cases.<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>