Re: Notes about Pl/PgSQL assignment performance

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andrey Zhidenkov <pensnarik(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Notes about Pl/PgSQL assignment performance
Date: 2017-12-19 11:49:06
Message-ID: CAFj8pRBsqRUJOHc_+Ms5Lo-_tAsmUnXYJ3v8LUSRsv9vASCxVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-12-19 12:45 GMT+01:00 Andrey Zhidenkov <pensnarik(at)gmail(dot)com>:

> When I run this test in 2 threads I expect that running time will be the
> same, because PostgreSQL will fork process for the second connection and
> this process will be served by a separate CPU core because I have more than
> 2 cores.
> Yes, IMMUTABLE flag helps, but I think It's just because Postgres actually
> executes procedure only once.
>

surely not - test it.

I am lazy think about it - but probably real reason is +/- execution of
read only transactions or possibly write transactions.

PostgreSQL is primary ACID database. You cannot to think about it like
scripting environment only.

Regards

Pavel

> On Tue, Dec 19, 2017 at 2:36 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> Hi
>>
>> 2017-12-19 12:28 GMT+01:00 Андрей Жиденков <pensnarik(at)gmail(dot)com>:
>>
>>> Few day ago a faced a problem: Pl/PgSQL procedure works slower when
>>> running in parallel threads. I found the correlation between number of
>>> assignments in procedure code and performance. I decided to write the
>>> simple benchmark procedures and perform some test on PostgreSQL 9.6.5
>>> database installed on the server with 20 CPU cores (2 Xeon E5-2690V2 CPUs).
>>>
>>> This benchmark showed me that a simple Pl/PgSQL procedure with a simple
>>> loop inside works slower when running even in 2 threads. There is a
>>> procedure:
>>>
>>> CREATE OR REPLACE FUNCTION benchmark_test() RETURNS VOID AS $$
>>> DECLARE
>>> v INTEGER; i INTEGER;
>>> BEGIN
>>> for i in 1..1000 loop
>>> v := 1;
>>> end loop;
>>> END;
>>> $$ LANGUAGE plpgsql;
>>>
>>> What is the point? I know, that Pl/PgSQL performs a SELECT query to
>>> calculate each value for assignment but I didn't expect that it produce
>>> side effects like this. If there is some buffer lock or anything else?
>>>
>>
>> I am little bit lost when you are speaking about threads. Postgres
>> doesn't use it.
>>
>> your test is not correct - benchmark_test should be marked as immutable.
>> What will be result?
>>
>> Regards
>>
>> Pavel
>>
>>
>>
>>
>>>
>>> I've been written a post with charts and detailed explanation to display
>>> these side effects: http://telegra.ph/Notes-about-PlPgSQL-assignment-pe
>>> rformance-12-19
>>>
>>> Any help would be greatly appreciated.
>>> --
>>>
>>>
>>
>
>
> --
> С уважением, Андрей Жиденков.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-12-19 11:54:24 Re: Notes about Pl/PgSQL assignment performance
Previous Message Pavel Stehule 2017-12-19 11:46:31 Re: Notes about Pl/PgSQL assignment performance