On Sat, 4 Jul 2020 at 01:19, Tom Lane wrote:
>
> I did some performance testing on 0001+0002 here, and found that
> for me, there's basically no change on x86_64 but a win of 2 to 3
> percent on aarch64, using Pavel's pi_est_1() as a representative
> case for simple plpgsql statements. That
I wrote:
> I attach your original 0003 here (it still applies, with some line
> offsets). That's just so the cfbot doesn't get confused about what
> it's supposed to test now.
Pushed that part now, too.
BTW, the first test run I did on this (on x86_64) was actually several
percent *slower* than
I did some performance testing on 0001+0002 here, and found that
for me, there's basically no change on x86_64 but a win of 2 to 3
percent on aarch64, using Pavel's pi_est_1() as a representative
case for simple plpgsql statements. That squares with your original
results I believe. It's not
On Thu, 2 Jul 2020 at 03:47, Tom Lane wrote:
>
> Amit Khandekar writes:
> > There are a couple of function call overheads I observed in pl/pgsql
> > code : exec_stmt() and exec_cast_value(). Removing these overheads
> > resulted in some performance gains.
>
> I took a look at the 0001/0002
Amit Khandekar writes:
> There are a couple of function call overheads I observed in pl/pgsql
> code : exec_stmt() and exec_cast_value(). Removing these overheads
> resulted in some performance gains.
I took a look at the 0001/0002 patches (not 0003 as yet). I do not
like 0001 too much. The
On Tue, 9 Jun 2020 at 21:49, Pavel Stehule wrote:
> Is your patch in commitfest in commitfest application?
Thanks for reminding me. Just added.
https://commitfest.postgresql.org/28/2590/
po 1. 6. 2020 v 15:59 odesílatel Amit Khandekar
napsal:
> On Mon, 1 Jun 2020 at 12:27, Pavel Stehule
> wrote:
> > po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar
> napsal:
> >>
> >> On Sat, 30 May 2020 at 11:11, Pavel Stehule
> wrote:
> >> > I think so the effect of these patches strongly
On Mon, 1 Jun 2020 at 12:27, Pavel Stehule wrote:
> po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar
> napsal:
>>
>> On Sat, 30 May 2020 at 11:11, Pavel Stehule wrote:
>> > I think so the effect of these patches strongly depends on CPU and compile
>>
>> I quickly tried pi() with gcc 10 as well,
po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar
napsal:
> On Sat, 30 May 2020 at 11:11, Pavel Stehule
> wrote:
> > I think so the effect of these patches strongly depends on CPU and
> compile
>
> I quickly tried pi() with gcc 10 as well, and saw more or less the
> same benefit. I think, we are
On Sat, 30 May 2020 at 11:11, Pavel Stehule wrote:
> I think so the effect of these patches strongly depends on CPU and compile
I quickly tried pi() with gcc 10 as well, and saw more or less the
same benefit. I think, we are bound to see some differences in the
benefits across architectures,
On Sun, 31 May 2020 at 08:04, Michael Paquier wrote:
> This stuff is interesting. Do you have some perf profiles to share?
> I am wondering what's the effect of the inlining with your test
> cases.
Below are the perf numbers for asignmany.sql :
HEAD :
+ 16.88% postgres postgres
On Sat, May 23, 2020 at 10:33:43PM +0530, Amit Khandekar wrote:
> By inlining of the two functions, found noticeable reduction in
> execution time as shown (figures are in milliseconds, averaged over
> multiple runs; taken from 'explain analyze' execution times) :
> ARM VM :
>HEAD : 100 ;
On Thu, 28 May 2020 at 14:39, Pavel Stehule wrote:
> I don't see 17% anywhere, but 3-5% is not bad.
Did you see 3-5% only for the pi function, or did you see the same
improvement also for the functions that I wrote ? I was getting a
consistent result of 14-18 % on both of the VMs. Also, is your
Hi
st 27. 5. 2020 v 13:31 odesílatel Amit Khandekar
napsal:
> On Tue, 26 May 2020 at 09:06, Amit Khandekar
> wrote:
> >
> > On Sat, 23 May 2020 at 23:24, Pavel Stehule
> wrote:
> > >
> > >FOR counter IN 1..180 LOOP
> > > id = 0; id = 0; id1 = 0;
> > > id2 = 0; id3 = 0; id1
On Tue, 26 May 2020 at 09:06, Amit Khandekar wrote:
>
> On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
> >
> >FOR counter IN 1..180 LOOP
> > id = 0; id = 0; id1 = 0;
> > id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> > id3 = 0; id = 0; id = 0; id1 = 0;
> > id2 = 0; id3
On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
>
>FOR counter IN 1..180 LOOP
> id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0; id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0;
>END LOOP;
>
> This is
Hi
so 23. 5. 2020 v 19:03 odesílatel Amit Khandekar
napsal:
> There are a couple of function call overheads I observed in pl/pgsql
> code : exec_stmt() and exec_cast_value(). Removing these overheads
> resulted in some performance gains.
>
> exec_stmt() :
>
> plpgsql_exec_function() and other
There are a couple of function call overheads I observed in pl/pgsql
code : exec_stmt() and exec_cast_value(). Removing these overheads
resulted in some performance gains.
exec_stmt() :
plpgsql_exec_function() and other toplevel block executors currently
call exec_stmt(). But actually they don't
18 matches
Mail list logo
