|From:||David Fetter <david(at)fetter(dot)org>|
|To:||Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>|
|Subject:||Re: Cached plans and statement generalization|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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:
> simple + autoprepare
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.
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
|Next Message||Andres Freund||2017-04-25 17:00:52||Re: PG 10 release notes|
|Previous Message||David G. Johnston||2017-04-25 16:45:27||Re: question: data file update when pg_basebackup in progress|