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 по дате отправления: