Re: Transient plans versus the SPI API

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Transient plans versus the SPI API
Дата
Msg-id 21817.1312399151@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Transient plans versus the SPI API  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Transient plans versus the SPI API  (Robert Haas <robertmhaas@gmail.com>)
Re: Transient plans versus the SPI API  (Yeb Havinga <yebhavinga@gmail.com>)
Re: Transient plans versus the SPI API  (Hannu Krosing <hannu@krosing.net>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> This seems like a good design.  Now what would be really cool is if
> you could observe a stream of queries like this:

> SELECT a, b FROM foo WHERE c = 123
> SELECT a, b FROM foo WHERE c = 97
> SELECT a, b FROM foo WHERE c = 236

> ...and say, hey, I could just make a generic plan and use it every
> time I see one of these.  It's not too clear to me how you'd make
> recognition of such queries cheap enough to be practical, but maybe
> someone will think of a way...

Hm, you mean reverse-engineering the parameterization of the query?
Interesting thought, but I really don't see a way to make it practical.

In any case, it would amount to making up for a bad decision on the
application side, ie, not transmitting the query in the parameterized
form that presumably exists somewhere in the application.  I think
we'd be better served all around by encouraging app developers to rely
more heavily on parameterized queries ... but first we have to fix the
performance risks there.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: mosbench revisited
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Further news on Clang - spurious warnings