Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3HhQ-0001wx-GB for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Apr 2017 07:49:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d3HhP-0006iv-Ns for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Apr 2017 07:49:19 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d3HhO-0006il-L6 for pgsql-hackers@postgresql.org; Wed, 26 Apr 2017 07:49:18 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3HhH-0004ng-4Y for pgsql-hackers@postgresql.org; Wed, 26 Apr 2017 07:49:17 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 46BA721C2A28; Wed, 26 Apr 2017 10:49:10 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Subject: Re: Cached plans and statement generalization DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1493192950; bh=+7HROTUuVuwfDQgVCDYFEdblmjoDfzk0X0xoHazoELQ=; h=To:References:From:Date:In-Reply-To; b=NI5PMIRQAGOzHacicJZj8E0cC7mXGxzz1+3yvUpARBCzv1Tt3tEFmQRreX4kVF+K3 muOFjyVFUzNRkV+LtG2vtCbZmmGz3lLWHBQhcnsqdaBjZPh/JQgb8js3p9AAt50Jgk iAXjGJzvlUpWcTrWgQSZu8pUG3rfUmgm1n/1EM4Q= To: "Tsunakawa, Takayuki" , "pgsql-hackers@postgresql.org" References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru> <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de> <0A3221C70F24FB45833433255569204D1F6EB258@G01JPEXMBYT05> From: Konstantin Knizhnik Message-ID: Date: Wed, 26 Apr 2017 10:49:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0A3221C70F24FB45833433255569204D1F6EB258@G01JPEXMBYT05> Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers