I wrote:
> I noticed that avocet and trilobite (two of our CLOBBER_CACHE_ALWAYS
> animals) have started to fail on the deadlock-parallel isolation
> test, with symptoms that look like they're timing out.
> ...
> The simplest fix is to force that test to use debug_discard_caches=0,
> but I don't lov
In the department of no-good-deed-goes-unpunished ...
I noticed that avocet and trilobite (two of our CLOBBER_CACHE_ALWAYS
animals) have started to fail on the deadlock-parallel isolation
test, with symptoms that look like they're timing out. Poking at
it here with a somewhat faster machine (a Ma
Tom Lane писал(а) 2025-04-02 21:09:
I wrote:
Anyway, I feel pretty good about this patch now and am quite content
to stop here for PG 18.
Since feature freeze is fast approaching, I did a tiny bit more
cosmetic work on this patchset and then pushed it. (There's still
plenty of time for adjust
05.04.2025 00:47, Tom Lane wrote:
Alexander Lakhin writes:
I've stumbled upon another defect introduced with 0dca5d68d:
CREATE FUNCTION f(VARIADIC ANYARRAY) RETURNS ANYELEMENT AS $$ SELECT x FROM
generate_series(1,1) g(i) $$ LANGUAGE SQL
IMMUTABLE;
SELECT f(1);
SELECT f(1);
Hmm, I see
regress
Alexander Lakhin writes:
> I've stumbled upon another defect introduced with 0dca5d68d:
> CREATE FUNCTION f(VARIADIC ANYARRAY) RETURNS ANYELEMENT AS $$ SELECT x FROM
> generate_series(1,1) g(i) $$ LANGUAGE SQL
> IMMUTABLE;
> SELECT f(1);
> SELECT f(1);
Hmm, I see
regression=# CREATE FUNCTION f
Hello Tom,
03.04.2025 22:13, Tom Lane wrpte:
Drat. I thought I'd tested the empty-function-body case, but
evidently that was a few changes too far back. Will fix,
thanks for catching it.
I've stumbled upon another defect introduced with 0dca5d68d:
CREATE FUNCTION f(VARIADIC ANYARRAY) RETURNS
Hello Tom,
02.04.2025 21:09, Tom Lane wrote:
Since feature freeze is fast approaching, I did a tiny bit more
cosmetic work on this patchset and then pushed it. (There's still
plenty of time for adjustments if you have further comments.)
I've discovered that starting from 0dca5d68d, the follow
Alexander Lakhin writes:
> I've discovered that starting from 0dca5d68d, the following query:
> CREATE FUNCTION f(x anyelement) RETURNS anyarray AS '' LANGUAGE SQL;
> SELECT f(0);
> triggers:
> TRAP: failed Assert("fcache->func->rettype == VOIDOID"), File: "functions.c",
> Line: 1737, PID: 37847
I wrote:
> Anyway, I feel pretty good about this patch now and am quite content
> to stop here for PG 18.
Since feature freeze is fast approaching, I did a tiny bit more
cosmetic work on this patchset and then pushed it. (There's still
plenty of time for adjustments if you have further comments.)
Alexander Pyhalov writes:
> I've looked through it and made some tests, including ones which
> caused me to create separate context for planing. Was a bit worried
> that it has gone, but now, as fcache->fcontext is deleted in the end
> of function execution, I don't see leaks, which were the initi
Hi.
Tom Lane писал(а) 2025-03-30 19:10:
I spent some time reading and reworking this code, and have
arrived at a patch set that I'm pretty happy with. I'm not
sure it's quite committable but it's close:
0005: This extracts the RLS test case you had and commits it
with the old non-failing be
Hi
> We get substantial wins on all of fx, fx3, fx4. fx2 is the
> case that gets inlined and never reaches functions.c, so the
> lack of change there is expected. What I found odd is that
> I saw a small speedup (~6%) on fx5 and fx6; those functions
> are in plpgsql so they really shouldn't cha
Alexander Pyhalov writes:
> After writing some comments, looking at it once again, I've found that
> one assumption is wrong - function can be discarded from cache during
> its execution.
Yeah. You really need a use-count on the shared cache object.
I've been working on pulling out plpgsql's
Alexander Pyhalov писал(а) 2025-03-28 15:22:
Tom Lane писал(а) 2025-03-14 23:52:
I spent some time today going through the actual code in this patch.
I realized that there's no longer any point in 0001: the later patches
don't move or repeatedly-call that bit of code, so it can be left
as-is.
Tom Lane писал(а) 2025-03-14 23:52:
I spent some time today going through the actual code in this patch.
I realized that there's no longer any point in 0001: the later patches
don't move or repeatedly-call that bit of code, so it can be left
as-is.
What I think we could stand to split out, tho
I spent some time today going through the actual code in this patch.
I realized that there's no longer any point in 0001: the later patches
don't move or repeatedly-call that bit of code, so it can be left as-is.
What I think we could stand to split out, though, is the changes in
the plancache sup
Tom Lane писал(а) 2025-03-13 21:29:
Pavel Stehule writes:
Maybe interesting change is the change of error message context
QUERY: SELECT public.dep_req2() || ' req3b'.
-CONTEXT: SQL function "dep_req3b" during startup
+CONTEXT: SQL function "dep_req3b" statement 1
I'm not hugely excite
Pavel Stehule writes:
> Maybe interesting change is the change of error message context
> QUERY: SELECT public.dep_req2() || ' req3b'.
> -CONTEXT: SQL function "dep_req3b" during startup
> +CONTEXT: SQL function "dep_req3b" statement 1
I'm not hugely excited about that given that it's just
Hi
I am checking last patches
Maybe interesting change is the change of error message context
QUERY: SELECT public.dep_req2() || ' req3b'.
-CONTEXT: SQL function "dep_req3b" during startup
+CONTEXT: SQL function "dep_req3b" statement 1
almost all SQL functions have just one statement, so s
Hi
čt 6. 3. 2025 v 9:57 odesílatel Alexander Pyhalov
napsal:
> Hi.
>
> Tom Lane писал(а) 2025-02-27 23:40:
> > Alexander Pyhalov writes:
> >> Now sql functions plans are actually saved. The most of it is a
> >> simplified version of plpgsql plan cache. Perhaps, I've missed
> >> something.
> >
>
Hi.
Tom Lane писал(а) 2025-02-27 23:40:
Alexander Pyhalov writes:
Now sql functions plans are actually saved. The most of it is a
simplified version of plpgsql plan cache. Perhaps, I've missed
something.
A couple of thoughts about v6:
* I don't think it's okay to just summarily do this:
Hi
pá 28. 2. 2025 v 7:29 odesílatel Pavel Stehule
napsal:
> Hi
>
> čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
>> >> So taken together, our results are all over the map, anywhere
>> >> from 7% speedup to
Hi
čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
> >> So taken together, our results are all over the map, anywhere
> >> from 7% speedup to 7% slowdown. My usual rule of thumb is that
>
> > Where do you see 7%
Alexander Pyhalov writes:
> Now sql functions plans are actually saved. The most of it is a
> simplified version of plpgsql plan cache. Perhaps, I've missed
> something.
A couple of thoughts about v6:
* I don't think it's okay to just summarily do this:
/* It's stale;
Pavel Stehule writes:
> čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
>> So taken together, our results are all over the map, anywhere
>> from 7% speedup to 7% slowdown. My usual rule of thumb is that
> Where do you see 7% speedup? Few lines up you wrote 0.7% faster.
Alexander got that on
čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
> > a.pyha...@postgrespro.ru> napsal:
> >>> Unfortunately, there is about 5% slowdown for inlined code, and for
> >>> just plpgsql code too.
>
> >> Hi. I've tried
Pavel Stehule writes:
> čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
> a.pyha...@postgrespro.ru> napsal:
>>> Unfortunately, there is about 5% slowdown for inlined code, and for
>>> just plpgsql code too.
>> Hi. I've tried to reproduce slowdown and couldn't.
> I'll try to get profiles.
čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
a.pyha...@postgrespro.ru> napsal:
> Pavel Stehule писал(а) 2025-02-26 22:34:
> > hI
> >
> > I can confirm 60% speedup for execution of function fx and fx3 - both
> > functions are very primitive, so for real code the benefit can be
> > higher
>
Pavel Stehule писал(а) 2025-02-26 22:34:
hI
I can confirm 60% speedup for execution of function fx and fx3 - both
functions are very primitive, so for real code the benefit can be
higher
Unfortunately, there is about 5% slowdown for inlined code, and for
just plpgsql code too.
I tested fx4
cr
hI
I can confirm 60% speedup for execution of function fx and fx3 - both
functions are very primitive, so for real code the benefit can be higher
Unfortunately, there is about 5% slowdown for inlined code, and for just
plpgsql code too.
I tested fx4
create or replace function fx4(int) returns i
Hi, folks.
I've looked through performance and found that most performance issues
was caused by CachedPlanSource machinery itself. At least, a lot of it.
And so decided to go along and implement plan cache for sql functions.
I'm not sure that it's clean enough, but at least it seems to be
wor
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 runti
Pavel Stehule writes:
> I did multiple benchmarking, and still looks so the proposed patch doesn't
> help and has significant overhead
Yeah, your fx() test case is clearly worse. For me,
HEAD:
regression=# do $$
begin
for i in 1..100 loop
perform fx((random()*100)::int); -- or fx2
Hi
I did multiple benchmarking, and still looks so the proposed patch doesn't
help and has significant overhead
testcase:
create or replace function fx(int) returns int as $$ select $1 + $1; $$
language sql immutable;
create or replace function fx2(int) returns int as $$ select 2 * $1; $$
langua
po 3. 2. 2025 v 17:00 odesílatel Tom Lane napsal:
> Pavel Stehule 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;
Pavel Stehule 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
Hi
čt 30. 1. 2025 v 9:50 odesílatel Alexander Pyhalov
napsal:
> Alexander Pyhalov писал(а) 2025-01-29 17:35:
> > Tom Lane писал(а) 2025-01-17 21:27:
> >> Alexander Pyhalov writes:
> >>> I've rebased patch on master. Tests pass here.
> >>
> >> The cfbot still doesn't like it; my guess is that yo
Alexander Pyhalov писал(а) 2025-01-29 17:35:
Tom Lane писал(а) 2025-01-17 21:27:
Alexander Pyhalov writes:
I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects on xml.out.
Hi. Thank
Tom Lane писал(а) 2025-01-17 21:27:
Alexander Pyhalov writes:
I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects on xml.out.
Hi. Thank you for review.
I've updated patch.
I've l
Alexander Pyhalov writes:
> I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects on xml.out.
I've looked through the patch briefly and have a few thoughts:
* You cannot use plancache.c l
Pavel Stehule писал(а) 2024-12-31 18:39:
Hi
út 31. 12. 2024 v 16:36 odesílatel Alexander Pyhalov
napsal:
Hi.
What should we do with "pre-parsed" SQL functions (when prosrc is
empty)? How should we create cached plans when we don't have raw
parsetrees?
Currently we can create cached plans wi
Hi
út 31. 12. 2024 v 16:36 odesílatel Alexander Pyhalov <
a.pyha...@postgrespro.ru> napsal:
> Hi.
>
> >> What should we do with "pre-parsed" SQL functions (when prosrc is
> >> empty)? How should we create cached plans when we don't have raw
> >> parsetrees?
> >> Currently we can create cached pla
Hi.
What should we do with "pre-parsed" SQL functions (when prosrc is
empty)? How should we create cached plans when we don't have raw
parsetrees?
Currently we can create cached plans without raw parsetrees, but this
means that plan revalidation doesn't work, choose_custom_plan()
always returns
Hi, Alexander!
On Tue, Sep 3, 2024 at 10:33 AM Alexander Pyhalov
wrote:
> Tom Lane писал(а) 2023-02-07 18:29:
> > Ronan Dunklau writes:
> >> The following comment can be found in functions.c, about the
> >> SQLFunctionCache:
> >
> >> * Note that currently this has only the lifespan of the calli
Tom Lane писал(а) 2023-02-07 18:29:
Ronan Dunklau writes:
The following comment can be found in functions.c, about the
SQLFunctionCache:
* Note that currently this has only the lifespan of the calling
query.
* Someday we should rewrite this code to use plancache.c to save
parse/plan
* r
Ronan Dunklau writes:
> The following comment can be found in functions.c, about the SQLFunctionCache:
> * Note that currently this has only the lifespan of the calling query.
> * Someday we should rewrite this code to use plancache.c to save parse/plan
> * results for longer than that.
> I w
Hello,
It has been brought to my attention that SQL functions always use generic
plans.
Take this function for example:
create or replace function test_plpgsql(p1 oid) returns text as $$
BEGIN
RETURN (SELECT relname FROM pg_class WHERE oid = p1 OR p1 IS NULL LIMIT 1);
END;
$$ language pl
47 matches
Mail list logo
