From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
cc: Alexander Pyhalov <a.pyhalov@postgrespro.ru>,
        Alexander Korotkov <aekorotkov@gmail.com>,
        pgsql-hackers@lists.postgresql.org,
        Ronan Dunklau <ronan.dunklau@aiven.io>
Subject: Re: SQLFunctionCache and generic plans
In-reply-to: <445556.1738612687@sss.pgh.pa.us>
References: <8216639.NyiUUSuA9g@aivenlaptop> <3084885.1675783797@sss.pgh.pa.us> <b69515864a7021505340f85476dc111e@postgrespro.ru> <CAPpHfdue9RVJKo33jKwrCeEXec0BTTH7CTxVcyXGMbfMExaGLA@mail.gmail.com> <758251661a3e8760ff52dd5c672a7505@postgrespro.ru> <CAFj8pRCoR9B+Ap70TQqWUa0PeeEk94D6VW20YbWN2Pm4b6-JMQ@mail.gmail.com> <30f02ca545915627905fbe3f23d93ec1@postgrespro.ru> <2275997.1737138456@sss.pgh.pa.us> <ad7296dd981c5f8eb76ff129913a55fd@postgrespro.ru> <51ebc5f3b846ce279b75ac4f5e5ac33f@postgrespro.ru> <CAFj8pRD2Fa84HoH_R_S5aKngyA6a+Au7U6NyidfBMrwEjFAc9g@mail.gmail.com> <401652.1738598448@sss.pgh.pa.us> <CAFj8pRC_4gEfmDoB5KbacNDdt3e6Tnf1z1BFK=MVp3+2kcDVqw@mail.gmail.com> <CAFj8pRA7MFTfUPwDDWtghaUvAjbrMHFUPbHyLSX3h8+FDw4WFg@mail.gmail.com> <445556.1738612687@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 03 Feb 2025 14:58:07 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <464676.1738620525.1@sss.pgh.pa.us>
Date: Mon, 03 Feb 2025 17:08:45 -0500
Message-ID: <464677.1738620525@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/464677.1738620525%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> But wait: HEAD takes
> Time: 6632.709 ms (00:06.633)
> to do the same thing.  So somehow the new-style SQL function
> stuff is very materially slower in this use-case, with or
> without this patch.  I do not understand why.

"perf" tells me that in the fx3 test, a full third of the runtime
is spent inside stringToNode(), with about three-quarters of that
going into pg_strtok().  This makes no sense to me: we'll be reading
the prosqlbody of fx3(), sure, but that's not enormously long (about
1200 bytes).  And pg_strtok() doesn't look remarkably slow.  There's
no way this should be taking more time than raw parsing + parse
analysis, even for such a trivial query as "select $1 + $1".

There's been some talk of getting rid of our existing nodetree
storage format in favor of something more efficient.  Maybe we
should put a higher priority on getting that done.  But anyway,
that seems orthogonal to the current patch.

> Even without cross-query plan caching, I don't see why the
> patch isn't better than it is.  It ought to be at least
> competitive with the unpatched code.

This remains true.

			regards, tom lane