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
fromquery. I am just copying bytes from one buffer to another. I do not try to somehow interpret this parameters. What
Iam 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