Greg Stark <st...@mit.edu> writes:
> On Wed, Sep 21, 2011 at 4:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
> Why couldn't they be in pg_proc with a bunch of opaque arguments like
> the GIST opclass support functions?
That does not mean the same thing at all. Everything in pg_proc is
meant to be called through the V0 or V1 function call info protocols.
> I'm a bit puzzled what the arguments would look like. They would still
> need to know the collation, nulls first/last flags, etc.
No, I wasn't thinking that we should do that. The datatype comparison
functions should have the exact same semantics they do now, just a
lower-overhead call mechanism. If you try to push stuff like NULLS
FIRST/LAST into the per-datatype code, then you are up against a problem
when you want to add a new flag: you have to touch lots of code not all
of which you even control.
> And calling it would still not be inlinable. So they would have to
> check those flags on each invocation instead of having a piece of
> straightline code that hard codes the behaviour with the right
> behaviour inline. ISTM the hope for a speedup from the inlining
> mostly came from the idea that the compiler might be able to hoist
> this logic outside the loop (and I suppose implement n specialized
> loops depending on the behaviour needed).
None of that stuff is inlinable or constant-foldable today, nor would it
be with the patch that Peter was proposing AFAICS, because none of the
flags will ever be compile time constant values.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
