Speedup idea: avoid using SQL procedures as aliases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Speedup idea: avoid using SQL procedures as aliases
Date: 1999-03-28 03:20:11
Message-ID: 11028.922591211@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-03-28 04:16:44 Parser doesn't grok unqualified array element
Previous Message Tom Lane 1999-03-28 02:27:10 Another new regress test