From: | Andrey Zhidenkov <pensnarik(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Notes about Pl/PgSQL assignment performance |
Date: | 2017-12-19 13:48:00 |
Message-ID: | CAN=gQ4B+Lkx2hVs9qY9q7jkjJv8gMJ04GO7FYTOHraxTy-5r9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've digged into the source code a little bit and found that chain:
PLPGSQL_STMT_ASSIGN -> exec_stmt_assign() -> exec_assign_expr()
-> exec_eval_expr() -> exec_run_select()
-> SPI_execute_plan_with_paramlist() -> _SPI_execute_plan() which finnaly
calls PushActiveSnapshot() and PopActiveSnapshot() wich just do memory
context allocations and use malloc() to copy snaphot.
Maybe I have missed something?
On Tue, Dec 19, 2017 at 4:34 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
> Andrey Zhidenkov wrote:
> > 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.
>
> Just a guess without actually looking at the WaitEvents (which you
> should do) is that this is blocking on snapshot acquisition or something
> like that.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
--
С уважением, Андрей Жиденков.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-12-19 13:52:56 | Re: WIP Patch: Pgbench Serialization and deadlock errors |
Previous Message | David Rowley | 2017-12-19 13:44:35 | Re: [HACKERS] path toward faster partition pruning |