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. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
