Message-ID: <58FFB309.5040209@postgrespro.ru>
Date: Tue, 25 Apr 2017 23:35:21 +0300
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: David Fetter <david@fetter.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: Cached plans and statement generalization
References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru>
 <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de>
 <f0bfcdd6-dba3-e9a8-2108-146e1f880839@postgrespro.ru>
 <20170425165421.GD32130@fetter.org>
In-Reply-To: <20170425165421.GD32130@fetter.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 04/25/2017 07:54 PM, David Fetter wrote:
> On Tue, Apr 25, 2017 at 06:11:09PM +0300, Konstantin Knizhnik wrote:
>> On 24.04.2017 21:43, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2017-04-24 11:46:02 +0300, Konstantin Knizhnik wrote:
>>>> So what I am thinking now is implicit query caching. If the same query with
>>>> different literal values is repeated many times, then we can try to
>>>> generalize this query and replace it with prepared query with
>>>> parameters.
>>> That's not actuall all that easy:
>>> - You pretty much do parse analysis to be able to do an accurate match.
>>>     How much overhead is parse analysis vs. planning in your cases?
>>> - The invalidation infrastructure for this, if not tied to to fully
>>>     parse-analyzed statements, is going to be hell.
>>> - Migrating to parameters can actually cause significant slowdowns, not
>>>     nice if that happens implicitly.
>> Well, first of all I want to share results I already get: pgbench with
>> default parameters,  scale 10 and one connection:
>>
>> protocol
>> 	TPS
>> simple
>> 	3492
>> extended
>> 	2927
>> prepared
>> 	6865
>> simple + autoprepare
>> 	6844
> If this is string mashing on the unparsed query, as it appears to be,
> it's going to be a perennial source of security issues.

Sorry, may be I missed something, but I can not understand how security can be violated by extracting string literals from query. I am just copying bytes from one buffer to another. I do not try to somehow interpret this parameters.  What I am doing is 
very similar with standard prepared statements.
And moreover query is parsed! Only query which was already parsed and executed (but with different values of parameters) can be autoprepared.


>
> Best,
> David.


-- 
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