Re: [HACKERS] Cached plans and statement generalization

Поиск
Список
Период
Сортировка
От Serge Rielau
Тема Re: [HACKERS] Cached plans and statement generalization
Дата
Msg-id CBF37923-CDA5-48EF-9E9E-4A338D7988ED@rielau.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Cached plans and statement generalization  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: [HACKERS] Cached plans and statement generalization  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers

On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
Another problem is caused by using integer literals in context where parameters can not be used, for example "order by 1”.
You will also need to deal with modifiers in types such as VARCHAR(10). Not sure if there are specific functions which can only deal with literals (?) as well.

Doug Doole did this work in DB2 LUW and he may be able to point to more places to watch out for semantically.

Generally, in my experience, this feature is very valuable when dealing with (poorly designed) web apps that just glue together strings.
Protecting it under a GUC would allow to only do the work if it’s deemed likely to help.
Another rule I find useful is to abort any efforts to substitute literals if any bind variable is found in the query.
That can be used as a cue that the author of the SQL left the remaining literals in on purpose.

A follow up feature would be to formalize different flavors of peeking. 
I.e. can you produce a generic plan, but still recruit the initial set of bind values/substituted literals to dos costing?

Cheers
Serge Rielau

PS: FWIW, I like this feature.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rui Hai Jiang
Дата:
Сообщение: [HACKERS] question: data file update when pg_basebackup in progress
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] pgbench tap tests & minor fixes