Re: Transient plans versus the SPI API

Поиск
Список
Период
Сортировка
От Anssi Kääriäinen
Тема Re: Transient plans versus the SPI API
Дата
Msg-id 4E3FC2ED.10406@thl.fi
обсуждение исходный текст
Ответ на Re: Transient plans versus the SPI API  (Hannu Krosing <hannu@2ndQuadrant.com>)
Список pgsql-hackers
On 08/08/2011 01:07 PM, Hannu Krosing wrote:
> That is why I think it is best done in the main parser - it has to parse
> and analyse the query anyway and likely knows which constants are
> "arguments" to the query
As far as I understand the problem, the parsing must transform table 
references to schema-qualified references. The table_foobar in "SELECT * 
FROM table_foobar WHERE id = ?" is not enough to identify a table. Using 
search_path, query_str as a key is one possibility, but the search_path 
is likely to be different for each user, and this could result in the 
same query being cached multiple times.

By the way, I checked current Git HEAD and pg_stat_statements seems to 
not handle search_path correctly. For pg_stat_statements this is not 
critical, but if the raw query string is used as plan cache key things 
will obviously break...
 - Anssi


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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs