Re: Add support for AT LOCAL

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Add support for AT LOCAL
Дата
Msg-id ZRyjgqDjBrl2o6l4@paquier.xyz
обсуждение исходный текст
Ответ на Re: Add support for AT LOCAL  (Vik Fearing <vik@postgresfriends.org>)
Список pgsql-hackers
On Tue, Oct 03, 2023 at 02:10:48AM +0200, Vik Fearing wrote:
> On 9/29/23 09:27, Michael Paquier wrote:
>> As the deparsing code introduced by this patch is showing, this leads
>> to a lot of extra complexity.  And, actually, this can be quite
>> expensive as well with these two layers of functions.  Note also that
>> in comparison to SQLValueFunctions, COERCE_SQL_SYNTAX does less
>> inlining.  So here comes my question: why doesn't this stuff just use
>> one underlying function to do this job?
>
> I guess I don't understand the question.  Why do you think a single function
> that repeats what these functions do would be preferable?  I am not sure how
> doing it a different way would be better.

Leaving aside the ruleutils.c changes introduced by the patch that are
quite confusing, having one function in the executor stack is going to
be more efficient than two (aka less ExecInitFunc), and this syntax
could be used in SQL queries where the operations is repeated a lot.
This patch introduces two COERCE_SQL_SYNTAX, meaning that we would do
twice the ACL check, twice the function hook, etc, so this could lead
to significant differences.  I think that we should be careful with
the approach taken, and do benchmarks to choose an efficient approach
from the start.  See for example:
https://www.postgresql.org/message-id/ZGHBGE45jKW8FEpe@paquier.xyz
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Index range search optimization