Speedup idea: avoid using SQL procedures as aliases

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Speedup idea: avoid using SQL procedures as aliases
Дата
Msg-id 11028.922591211@sss.pgh.pa.us
обсуждение исходный текст
Список pgsql-hackers
I noticed just now that there are a lot of SQL-language procedures in
pg_proc whose only purpose is to provide alternative names for built-in
functions.  For example, none of the seven functions named "float8"
is actually a built-in; they are all SQL aliases for built-in functions
like i4tod().

It strikes me that this is pretty inefficient.  For example, converting
an int4 column to float seems to take about twice as long if you do it
with float8(int4column) as if you do it with i4tod(int4column), because
the former involves a level of SQL overhead.

I am thinking about fixing this by decoupling the user-level name of
an internal function from its C-language name.  The simplest way seems
to be to modify pg_proc.h and Gen_fmgrtab.sh.in so that the C-language
name of an internal function is stored in pg_proc's "prosrc" field
(which is currently unused for internal functions) rather than being
taken from "proname".  Then, all of the SQL functions that are simply
aliases for internal functions could be converted to plain internal
function entries that have proname different from prosrc.

Anyone have an objection to this?  I suppose we'd need to check that
the regression tests still exercise SQL functions ;-)
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Another new regress test
Следующее
От: Tom Lane
Дата:
Сообщение: Parser doesn't grok unqualified array element