From: | Юрий Соколов <funny(dot)falcon(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Cached plans and statement generalization |
Date: | 2021-04-25 18:57:10 |
Message-ID: | CAL-rCA1r+Pvcg4Y6hm00UDtT0_DhjyFjvswaronv7N7Yb+iPhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
вс, 1 мар. 2020 г. в 22:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> > [ autoprepare-extended-4.patch ]
>
> The cfbot is showing that this doesn't apply anymore; there's
> some doubtless-trivial conflict in prepare.c.
>
> However ... TBH I've been skeptical of this whole proposal from the
> beginning, on the grounds that it would probably hurt more use-cases
> than it helps. The latest approach doesn't really do anything to
> assuage that fear, because now that you've restricted it to extended
> query mode, the feature amounts to nothing more than deliberately
> overriding the application's choice to use unnamed rather than named
> (prepared) statements. How often is that going to be a good idea?
> And when it is, wouldn't it be better to fix the app? The client is
> likely to have a far better idea of which statements would benefit
> from this treatment than the server will; and in this context,
> the client-side changes needed would really be trivial. The original
> proposal, scary as it was, at least supported the argument that you
> could use it to improve applications that were too dumb/hoary to
> parameterize commands for themselves.
The theme of this thread:
- it is not possible to reliably "fix the app" when pgbouncer or internal
driver connection multiplexing are used.
- another widely spread case is frameworks (ORM or other).
There is no way to prepare a concrete query because it is buried under
levels of abstractions.
Whole "autoprepare" thing is a workaround for absence of "really trivial
client-side changes" in these conditions.
regards,
Yura
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-25 19:13:58 | Re: Allowing to create LEAKPROOF functions to non-superuser |
Previous Message | Stephen Frost | 2021-04-25 18:40:54 | Re: Allowing to create LEAKPROOF functions to non-superuser |