| From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
|---|---|
| To: | Serge Rielau <serge(at)rielau(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Doug Doole <ddoole(at)salesforce(dot)com> |
| Subject: | Re: Cached plans and statement generalization |
| Date: | 2017-04-25 20:47:44 |
| Message-ID: | 58FFB5F0.2020900@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/25/2017 11:40 PM, Serge Rielau wrote:
>
>> On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru <mailto:k(dot)knizhnik(at)postgrespro(dot)ru>> wrote:
>>>
>>>
>>> SELECT ‘hello’::CHAR(10) || ‘World’, 5 + 6;
>>>
>>> You can substitute ‘hello’, ‘World’, 5, and 6. But not 10.
>>
>> I am substituting only string literals. So the query above will be transformed to
>>
>> SELECT $1::CHAR(10) || $2, 5 + 6;
>>
>> What's wrong with it?
>
> Oh, well that leaves a lot of opportunities on the table, doesn’t it?
Well, actually my primary intention was not to make badly designed programs (not using prepared statements) work faster.
I wanted to address cases when it is not possible to use prepared statements.
If we want to substitute with parameters as much literals as possible, then parse+deparse tree seems to be the only reasonable approach.
I will try to implement it also, just to estimate parsing overhead.
>
> Cheers
> Serge
>
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-25 20:56:44 | Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly |
| Previous Message | Serge Rielau | 2017-04-25 20:40:10 | Re: Cached plans and statement generalization |