Re: Rethinking plpgsql's assignment implementation

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Rethinking plpgsql's assignment implementation
Дата
Msg-id CAFj8pRDH6PMG-4ozgeapoM4EKP6dKi1ZFyxyB_8=PZ2iZChKMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rethinking plpgsql's assignment implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rethinking plpgsql's assignment implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


po 14. 12. 2020 v 17:25 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I checked a performance and it looks so access to record's field is faster,
> but an access to arrays field is significantly slower

Hmm, I'd drawn the opposite conclusion in my own testing ...

>     for i in 1..5000
>     loop
>       if a[i] > a[i+1] then
>         aux := a[i];
>         a[i] := a[i+1]; a[i+1] := aux;
>         rep := true;
>       end if;
>     end loop;

... but I now see that I'd not checked cases like "a[i] := a[j]".
exec_check_rw_parameter() is being too conservative about whether
it can optimize a case like that.  The attached incremental patch
fixes it.

> I tested pi calculation
> ...
> And the performance is 10% slower than on master

Can't reproduce that here.  For the record, I get the following
timings (medians of three runs) for your test cases:

HEAD:

sort:                   Time: 13974.709 ms (00:13.975)
pi_est_1(10000000):     Time: 3537.482 ms (00:03.537)
pi_est_2(10000000):     Time: 3546.557 ms (00:03.547)

Patch v1:

sort:                   Time: 47053.892 ms (00:47.054)
pi_est_1(10000000):     Time: 3456.078 ms (00:03.456)
pi_est_2(10000000):     Time: 3451.347 ms (00:03.451)

+ exec_check_rw_parameter fix:

sort:                   Time: 12199.724 ms (00:12.200)
pi_est_1(10000000):     Time: 3357.955 ms (00:03.358)
pi_est_2(10000000):     Time: 3367.526 ms (00:03.368)

I'm inclined to think that the differences in the pi calculation
timings are mostly chance effects; there's certainly no reason
why exec_check_rw_parameter should affect that test case at all.

performance patch helps lot of for sort - with patch it is faster 5-10% than master 10864 x 12122 ms

I found probably reason why patched was slower

I used

CFLAGS="-fno-omit-frame-pointer -Wall -Wmissing-prototypes -Wdeclaration-after-statement  -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -Werror=switch"

With these options the pi test was slower. When I used default, then there is no difference.

So it can be very good feature, new code has same speed or it is faster

Regards

Pavel










                        regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniil Zakhlystov
Дата:
Сообщение: Re: libpq compression
Следующее
От: John Naylor
Дата:
Сообщение: Re: cutting down the TODO list thread