Re: PostgreSQL Function Language Performance: C vs PL/PGSQL

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
Дата
Msg-id 20100526163251.GB21875@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: PostgreSQL Function Language Performance: C vs PL/PGSQL  (Eliot Gable <egable+pgsql-performance@gmail.com>)
Ответы Re: PostgreSQL Function Language Performance: C vs PL/PGSQL  (Eliot Gable <egable+pgsql-performance@gmail.com>)
Список pgsql-performance
* Eliot Gable (egable+pgsql-performance@gmail.com) wrote:
> Thanks for the quick follow-up. So, you are saying that if I can do SPI in
> _PG_init, then I could prepare all my queries there and they would be
> prepared once for the entire function when it is loaded? That would
> certainly achieve what I want. Does anybody know whether I can do SPI in
> _PG_init?

Unless you're using EXECUTE in your pl/pgsql, the queries in your
pl/pgsql function are already getting prepared on the first call of the
function for a given backend connection..  If you're using EXECUTE in
pl/gpsql then your problem might be planning time.  Moving that to C
isn't going to change things as much as you might hope if you still have
to plan the query every time you call it..

> The function gets called a lot, but not in the same transaction. It is only
> called once per transaction.

That's not really relevant..  Is it called alot from the same
backend/database connection?  If so, and if you're using regular SELECT
statements and the like (not EXECUTE), then they're getting prepared the
first time they're used and that is kept across transactions.

    Thanks,

        Stephen

Вложения

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

Предыдущее
От: David Jarvis
Дата:
Сообщение: Re: Random Page Cost and Planner
Следующее
От: Eliot Gable
Дата:
Сообщение: Re: PostgreSQL Function Language Performance: C vs PL/PGSQL