Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d37NH-0005M6-9l for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 20:47:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d37NG-0001oz-Mb for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 20:47:50 +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 1d37NE-0001nr-TL for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 20:47:49 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d37NB-0000br-R8 for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 20:47:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id F0D3E21C2A28; Tue, 25 Apr 2017 23:47:44 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Message-ID: <58FFB5F0.2020900@postgrespro.ru> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1493153264; bh=/NynLw2Y3tYHS/c6q8Fn9/08V97o1IrfycFsUQozy38=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=KZozKGFgnzaYcvTiDgt9klmXMec8HEvKdYF+PUFujSGO4MCQoHRyqk7uwOSyaOhL4 PDhvJvsdve/HXAnLd+D1MJaJpa3b7Z3Zsyk7G5J1K4jiPHW0fX1EekU7ggKCUiUfQU WDe3eQYd+4WaQQT1Ni1XFUxACR2g4hjczvNTVA+E= Date: Tue, 25 Apr 2017 23:47:44 +0300 From: Konstantin Knizhnik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Serge Rielau CC: Pg Hackers , Doug Doole Subject: Re: Cached plans and statement generalization References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru> <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de> <1f4c1a22-ecbe-811d-4695-ee4701b8f6c7@postgrespro.ru> <58FFB391.5080101@postgrespro.ru> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070500010500060803060801" 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 This is a multi-part message in MIME format. --------------070500010500060803060801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/25/2017 11:40 PM, Serge Rielau wrote: > >> On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik > wrote: >>> >>> >>> SELECT ‘hello’::CHAR(10) || ‘World’, 5 + 6; >>> >>> You can substitute ‘hello’, ‘World’, 5, and 6. But not 10. >> >> I am substituting only string literals. So the query above will be transformed to >> >> SELECT $1::CHAR(10) || $2, 5 + 6; >> >> What's wrong with it? > > Oh, well that leaves a lot of opportunities on the table, doesn’t it? Well, actually my primary intention was not to make badly designed programs (not using prepared statements) work faster. I wanted to address cases when it is not possible to use prepared statements. If we want to substitute with parameters as much literals as possible, then parse+deparse tree seems to be the only reasonable approach. I will try to implement it also, just to estimate parsing overhead. > > Cheers > Serge > -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --------------070500010500060803060801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 04/25/2017 11:40 PM, Serge Rielau wrote:

On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:

SELECT ‘hello’::CHAR(10) || ‘World’, 5 + 6;

You can substitute ‘hello’, ‘World’, 5, and 6. But not 10.

I am substituting only string literals. So the query above will be transformed to

SELECT $1::CHAR(10) || $2, 5 + 6;

What's wrong with it?

Oh, well that leaves a lot of opportunities on the table, doesn’t it?

Well, actually my primary intention was not to make badly designed programs (not using prepared statements) work faster.
I wanted to address cases when it is not possible to use prepared statements.
If we want to substitute with parameters as much literals as possible, then parse+deparse tree seems to be the only reasonable approach.
I will try to implement it also, just to estimate parsing overhead.




Cheers
Serge



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