<div>Thank you for the clarification.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Sep 2022 at 3:47 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>
> I am not sure I understood what you mean when you mentioned “close message”<br>
> <br>
> But i’ll try to ask you in a different way.<br>
> <br>
> Let look on the following example:<br>
> <br>
> 1. Select * from users where id = $1; using extended query. —> miss<br>
> <br>
> 2. Now in case i’ll run the same query i’ll get it back from cache.<br>
> <br>
> So I am understanding why the parse message should be pass to the backend<br>
> and not read the result from cache due to that Parse message didn’t<br>
> contains the query params. That’s make sense.<br>
> <br>
> But in Bind message the packet already contains the query params. So why<br>
> you can’t read the result from cache here and we need to wait to the<br>
> execute message?<br>
<br>
Bind message does not return the "result". It just returns it succeeded<br>
(bind complete message) or failed (error response). The actual result<br>
(which is called "portal") is only in PostgreSQL's memory. So "caching<br>
result of bind message" is almost meaningless.<br>
<br>
> One more question is why we need to send the bind message anyway to the<br>
> backend in case we have already the result of the execute message in cache?<br>
<br>
Think about this scenario:<br>
<br>
1. pgpool receives a bind message but finds that the corresponding<br>
query cache exists. So pgpool does not send the bind message to<br>
backend.<br>
<br>
2. In other session the table used in the query has been modified and<br>
the query is gone.<br>
<br>
3. pgpool receives an execute message and tries to extract the query<br>
cache, but it has already gone. However pgpool cannot send the execute<br>
message to backend because the result of bind message (portal) does<br>
not exist in the backend.<br>
<br>
> I am asking the above questions because I am looking in the rds performance<br>
> insights.<br>
> And I can see that in case I am sending a lot of queries concurrently when<br>
> I have cache enabled I can see a very big wait because of a lot of<br>
> connections in idle ClientRead wait event.<br>
<br>
I am not familiar with performance insights and cannot comment on it.<br>
<br>
> And I am asking myself why the db needs to know about queries we already<br>
> have in cache?<br>
> <br>
> Hope it was clear.<br>
> <br>
> <br>
> Thanks a lot,<br>
> <br>
> Avi<br>
> <br>
> <br>
> <br>
> On Wed, 14 Sep 2022 at 2:42 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
> <br>
>> > Hi,<br>
>> ><br>
>> > In case query already cached, why in extended query mode the db knows<br>
>> 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>
>><br>
</blockquote></div></div>