Re: Inlining comparators as a performance optimisation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inlining comparators as a performance optimisation
Date
Msg-id 24658.1316622469@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inlining comparators as a performance optimisation  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 21.09.2011 18:46, Tom Lane wrote:
>> Well, we'd have to negotiate what the API ought to be.  What I'm
>> envisioning is that datatypes could provide alternate comparison
>> functions that are designed to be qsort-callable rather than
>> SQL-callable.  As such, they could not have entries in pg_proc, so
>> it seems like there's no ready way to represent them in the catalogs.

> Quite aside from this qsort-thing, it would be nice to have versions of 
> all simple functions that could be called without the FunctionCall 
> overhead.

Hmm, that's an interesting idea.  I think probably the important aspects
are (1) known number of arguments and (2) no null argument or result
values are allowed.  Not sure what we'd do with collations though.

> We could have an extended version of the PG_FUNCTION_INFO_V1 macro that 
> would let you register the fastpath function:
> PG_FUNCTION_INFO_V1(int4pl, int4pl_fastpath);

We don't use PG_FUNCTION_INFO_V1 for built-in functions ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Next
From: Daniel Vázquez
Date:
Subject: unaccent contrib