Re: plans for PostgreSQL 12 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plans for PostgreSQL 12
Date
Msg-id CAFj8pRAwg7df5wJ-JF2FVhUqgzZn89GcTEguC8G3725AEHzzag@mail.gmail.com
Whole thread Raw
In response to Re: plans for PostgreSQL 12  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers


2018-06-05 15:00 GMT+02:00 Andres Freund <andres@anarazel.de>:
Hi,

On 2018-06-05 06:32:31 +0200, Pavel Stehule wrote:
> ./configure --with-libxml --enable-tap-tests --enable-debug --with-perl
> CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer"
>
> [pavel@nemesis postgresql]$ gcc --version
> gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
>
> I executed simple script
>
>  do $$ declare i bigint = 1; s bigint = 0; begin while i <= 100000000 loop
> s := s + i; i := i + 1; end loop;  raise notice '%', s; end $$;
>
>    7,68%  postmaster  postgres           [.]
> GetSnapshotData                               ▒
>    7,53%  postmaster  plpgsql.so         [.]
> exec_eval_simple_expr                         ▒
>    6,49%  postmaster  postgres           [.]

It seems to me the right fix here isn't a new class of functions, but
rather support for delaying the computation of the snapshot to the point
it's needed.  That'll be far more generically applicable and doesn't
require user interaction.

good idea. Can be quick fix.


> ExecInterpExpr                                ▒
>    4,13%  postmaster  postgres           [.]

So we're going to need to optimize this further as well, I've a pending
patch for that, luckily ;)

nice :)


> LWLockRelease                                 ▒
>    4,12%  postmaster  postgres           [.]

That's also GetSnapshotData()...

there are about 10% locking, unlocking plan cache still.

Regards

Pavel


Greetings,

Andres Freund

pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: adding tab completions
Next
From: Andrew Dunstan
Date:
Subject: automating perl compile time checking