Re: SQLFunctionCache and generic plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQLFunctionCache and generic plans
Date
Msg-id 401652.1738598448@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQLFunctionCache and generic plans  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> Did you do some performance checks?

This is a good question to ask ...

> I tried some worst case

> CREATE OR REPLACE FUNCTION fx(int)
> RETURNS int AS $$
> SELECT $1 + $1
> $$ LANGUAGE SQL IMMUTABLE;

... but I don't think tests like this will give helpful answers.
That function is simple enough to be inlined:

regression=# explain verbose select fx(f1) from int4_tbl;
                          QUERY PLAN                           
---------------------------------------------------------------
 Seq Scan on public.int4_tbl  (cost=0.00..1.06 rows=5 width=4)
   Output: (f1 + f1)
(2 rows)

So functions.c shouldn't have any involvement at all in the
actually-executed PERFORM expression, and whatever difference
you measured must have been noise.  (If the effect *is* real,
we'd better find out why.)

You need to test with a non-inline-able function.  Looking
at the inlining conditions in inline_function(), one simple
hack is to make the function return SETOF.  That'll only
exercise the returns-set path in functions.c though, so it'd
be advisable to check other inline-blocking conditions too.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()
Next
From: Sami Imseih
Date:
Subject: Re: Doc fix of aggressive vacuum threshold for multixact members storage