Re: [HACKERS] Cached plans and statement generalization - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: [HACKERS] Cached plans and statement generalization
Date
Msg-id bda56ce2-64fa-8236-b3a9-71db71b41c6b@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] Cached plans and statement generalization  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: [HACKERS] Cached plans and statement generalization  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers

On 26.04.2017 04:00, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Konstantin
>> Knizhnik
>> Well, first of all I want to share results I already get: pgbench with default
>> parameters,  scale 10 and one connection:
>>
>> So autoprepare is as efficient as explicit prepare and can increase
>> performance almost two times.
> This sounds great.
>
> BTW, when are the autoprepared statements destroyed?
Right now them are destroyed only in case of receiving invalidation  
message (when catalog is changed).
Prepared statements are local to backend and are located in backend's  
memory.
It is unlikely, that there will be too much different queries which  
cause memory overflow.
But in theory such situation is certainly possible.


>   Are you considering some upper limit on the number of prepared statements?
In this case we need some kind of LRU for maintaining cache of  
autoprepared statements.
I think that it is good idea to have such limited cached - it can avoid  
memory overflow problem.
I will try to implement it.


> Regards
> Takayuki Tsunakawa
>
>

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] statement_timeout is not working as expected withpostgres_fdw