I wrote:
> Amit Langote writes:
>> One thing -- I don't get the division between
>> CachedPlanAllowsSimpleValidityCheck() and CachedPlanIsSimplyValid().
>> Maybe I am missing something, but could there not be just one
>> function, possibly using whether expr_simple_expr is set or not to
>> skip or
Andres Freund writes:
> On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
>> Testing that reminded me of the other regression test failure I'd seen
>> when I first tried to do it: select_parallel.sql shows a WARNING about
>> a plancache leak in a parallel worker process. When I looked into the
>> rea
Andres Freund writes:
> On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
>> + * This function, together with CachedPlanIsSimplyValid, provides a fast
>> path
>> + * for revalidating "simple" generic plans. The core requirement to be
>> simple
>> + * is that the plan must not require taking any loc
Hi,
On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
> I wrote:
> > I had a thought about a possibly-cleaner way to do this. We could invent
> > a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that
> > explicitly releases all plancache pins it knows about. So plpgsql
> > would not ca
I wrote:
> I had a thought about a possibly-cleaner way to do this. We could invent
> a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that
> explicitly releases all plancache pins it knows about. So plpgsql
> would not call the regular ResourceOwnerRelease entry point at all,
> but
Amit Langote writes:
> One thing -- I don't get the division between
> CachedPlanAllowsSimpleValidityCheck() and CachedPlanIsSimplyValid().
> Maybe I am missing something, but could there not be just one
> function, possibly using whether expr_simple_expr is set or not to
> skip or do, resp., the
Andres Freund writes:
> On 2020-03-25 17:51:50 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Hm, any chance that the multiple resowner calls here could show up in a
>>> profile? Probably not?
>> Doubt it. On the other hand, as the code stands it's certain that the
>> resowner contains not
On Thu, Mar 26, 2020 at 4:44 AM Tom Lane wrote:
>
> Pavel Stehule writes:
> > I'll mark this patch as ready for commiters.
>
> Thanks for reviewing! Amit, do you have any thoughts on this?
Thanks for picking this up. Test cases added by your patch really
shows why the plancache and the planner
Andres Freund writes:
> I'm still confused by the comment I was reacting to - the code
> explicitly is about creating the *shared* resowner:
Right, this is because of the choice I mentioned earlier about creating
this resowner the same way as the one for the inline case. I guess the
comments cou
Hi,
On 2020-03-25 19:15:28 -0400, Tom Lane wrote:
> >> The comment is there because the regression tests fall over if you try
> >> to do it the other way :-(. The failure I saw was specific to a
> >> transaction being done in a DO block, and maybe we could handle that
> >> differently from the ca
Andres Freund writes:
> On 2020-03-25 17:51:50 -0400, Tom Lane wrote:
>> Perhaps, but I'm not sure that either of those functions represent
>> material overhead in cases besides this one.
> That's not huge, but also not nothing.
I see. So maybe worth the trouble --- but still, seems like materi
Hi,
On 2020-03-25 17:51:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if it'd make sense to store the locks needed for
> > AcquirePlannerLocks/AcquireExecutorLocks in a better form.
>
> Perhaps, but I'm not sure that either of those functions represent
> material overhead in cas
Andres Freund writes:
> I wonder if it'd make sense to store the locks needed for
> AcquirePlannerLocks/AcquireExecutorLocks in a better form.
Perhaps, but I'm not sure that either of those functions represent
material overhead in cases besides this one.
> Would it make sense to instead compute
Hi,
On 2020-03-21 14:24:05 -0400, Tom Lane wrote:
> So while there's clearly something worth pursuing here, I do not like
> anything about the way it was done. I think that the right way to
> think about this problem is "how can the plan cache provide a fast
> path for checking validity of simple
On Sat, Mar 21, 2020 at 2:24 PM Tom Lane wrote:
> With this patch, perf shows the hotspots on Pavel's original example
> as being
>
> + 19.24%19.17% 46470 postmaster plpgsql.so
> [.] exec_eval_expr
> + 15.19%15.15% 36720 postmaster plpgs
Pavel Stehule writes:
> I'll mark this patch as ready for commiters.
Thanks for reviewing! Amit, do you have any thoughts on this?
regards, tom lane
so 21. 3. 2020 v 21:29 odesílatel Pavel Stehule
napsal:
>
>
> so 21. 3. 2020 v 19:24 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > So the patch has a problem with constant casting - unfortunately the
>> mix of
>> > double precision variables and numeric constants is pretty often i
so 21. 3. 2020 v 19:24 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > So the patch has a problem with constant casting - unfortunately the mix
> of
> > double precision variables and numeric constants is pretty often in
> > Postgres.
>
> Yeah. I believe the cause of that is that the pa
Pavel Stehule writes:
> So the patch has a problem with constant casting - unfortunately the mix of
> double precision variables and numeric constants is pretty often in
> Postgres.
Yeah. I believe the cause of that is that the patch thinks it can skip
passing an inline-function-free simple expr
Hi
I did another test
I use a pi estimation algorithm and it is little bit more realistic than
just almost empty cycle body - still probably nobody will calculate pi in
plpgsql.
CREATE OR REPLACE FUNCTION pi_est(n int)
RETURNS numeric AS $$
DECLARE
accum double precision DEFAULT 1.0;
c1 doub
čt 19. 3. 2020 v 10:47 odesílatel Amit Langote
napsal:
> Hi Pavel,
>
> Sorry it took me a while to look at this.
>
> On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule
> wrote:
> > po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
> napsal:
> >> But I found one issue - I don't know if this issue is re
čt 19. 3. 2020 v 10:47 odesílatel Amit Langote
napsal:
> Hi Pavel,
>
> Sorry it took me a while to look at this.
>
> On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule
> wrote:
> > po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
> napsal:
> >> But I found one issue - I don't know if this issue is re
Hi Pavel,
Sorry it took me a while to look at this.
On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule wrote:
> po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
> napsal:
>> But I found one issue - I don't know if this issue is related to your patch
>> or plpgsql_check.
>>
>> plpgsql_check try to c
Hi David,
On Tue, Mar 17, 2020 at 8:53 PM David Steele wrote:
>
> Hi Amit,
>
> On 2/25/20 3:42 AM, Amit Langote wrote:
> > On Tue, Feb 25, 2020 at 4:16 PM Pavel Stehule
> > wrote:
> >> I added this patch to a commitfest
> >>
> >> https://commitfest.postgresql.org/27/2467/
> >>
> >> It is very i
Hi Amit,
On 2/25/20 3:42 AM, Amit Langote wrote:
On Tue, Feb 25, 2020 at 4:16 PM Pavel Stehule wrote:
I added this patch to a commitfest
https://commitfest.postgresql.org/27/2467/
It is very interesting speedup and it is in good direction to JIT expressions
Thank you. I was planning to do
Hi Pavel,
On Tue, Feb 25, 2020 at 4:16 PM Pavel Stehule wrote:
>
> Hi
>
> I added this patch to a commitfest
>
> https://commitfest.postgresql.org/27/2467/
>
> It is very interesting speedup and it is in good direction to JIT expressions
Thank you. I was planning to do that myself.
I will take
Hi
I added this patch to a commitfest
https://commitfest.postgresql.org/27/2467/
It is very interesting speedup and it is in good direction to JIT
expressions
Pavel
po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
napsal:
>
>
> po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
>> napsal:
>>
>>>
>>>
>>> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
>>> napsal:
>>>
On Wed, Feb 19, 2020 a
po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule
napsal:
>
>
> čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
>> napsal:
>>
>>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote
>>> wrote:
>>> > On Wed, Feb 19, 2020 at 3:38 PM Pavel
čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
napsal:
>
>
> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
> napsal:
>
>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote
>> wrote:
>> > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule
>> wrote:
>> > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule <
st 19. 2. 2020 v 8:09 odesílatel Amit Langote
napsal:
> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote
> wrote:
> > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule
> wrote:
> > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com> napsal:
> > >> út 18. 2. 2020 v 17:08 odesíl
On Wed, Feb 19, 2020 at 3:56 PM Amit Langote wrote:
> On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule wrote:
> > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
> > napsal:
> >> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
> >> napsal:
> >>> > I updated the patch to do that.
> >>> >
> >>> > Wi
On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule wrote:
> st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
> napsal:
>> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
>> napsal:
>>> > I updated the patch to do that.
>>> >
>>> > With the new patch, `select foo()`, with inline-able sql_incr() in it,
st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
napsal:
>
>
> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
> napsal:
>
>> On Tue, Feb 18, 2020 at 6:56 PM Amit Langote
>> wrote:
>> > On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule
>> wrote:
>> > > út 18. 2. 2020 v 6:03 odesílatel Amit Langote <
út 18. 2. 2020 v 17:08 odesílatel Amit Langote
napsal:
> On Tue, Feb 18, 2020 at 6:56 PM Amit Langote
> wrote:
> > On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule
> wrote:
> > > út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> napsal:
> > >> I didn't send the patch, because it didn't handle the c
On Tue, Feb 18, 2020 at 6:56 PM Amit Langote wrote:
> On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule wrote:
> > út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> > napsal:
> >> I didn't send the patch, because it didn't handle the cases where a
> >> simple expression consists of an inline-able fun
On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule wrote:
> út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> napsal:
>> I didn't send the patch, because it didn't handle the cases where a
>> simple expression consists of an inline-able function(s) in it, which
>> are better handled by a full-fledged p
út 18. 2. 2020 v 6:03 odesílatel Amit Langote
napsal:
> Hi,
>
> On Sun, Feb 16, 2020 at 11:13 PM Pavel Stehule
> wrote:
> > when I do some profiling of plpgsql, usually I surprised how significant
> overhead has expression execution. Any calculations are very slow.
> >
> > This is not typical ex
Hi,
On Sun, Feb 16, 2020 at 11:13 PM Pavel Stehule wrote:
> when I do some profiling of plpgsql, usually I surprised how significant
> overhead has expression execution. Any calculations are very slow.
>
> This is not typical example of plpgsql, but it shows cleanly where is a
> overhead
>
> CR
ne 16. 2. 2020 v 15:12 odesílatel Pavel Stehule
napsal:
> Hi
>
> when I do some profiling of plpgsql, usually I surprised how significant
> overhead has expression execution. Any calculations are very slow.
>
> This is not typical example of plpgsql, but it shows cleanly where is a
> overhead
>
>
Hi
when I do some profiling of plpgsql, usually I surprised how significant
overhead has expression execution. Any calculations are very slow.
This is not typical example of plpgsql, but it shows cleanly where is a
overhead
CREATE OR REPLACE FUNCTION public.foo()
RETURNS void
LANGUAGE plpgsql
41 matches
Mail list logo
