Re: Postgres with pthread

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres with pthread
Date: 2017-12-08 22:28:35
Message-ID: CAPpHfdsvg-cgMi95a-CAyirbEk8hfoaaGGAi1OU1cSYd7v68BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 9, 2017 at 1:09 AM, konstantin knizhnik <
k(dot)knizhnik(at)postgrespro(dot)ru> wrote:

> I am not going to show stack traces of all 1000 threads.
> But you may notice that proc array lock really seems be be a bottleneck.
>

Yes, proc array lock easily becomes a bottleneck on multicore machine with
large number of connections. Related to this, another patch helping to
large number of connections is CSN. When our snapshot model was invented,
xip was just array of few elements, and that cause no problem. Now, we're
considering threads to help us handling thousands of connections. Snapshot
with thousands of xips looks ridiculous. Collecting such a large snapshot
could be more expensive than single index lookup.

These two patches threads and CSN are both complicated and require hard
work during multiple release cycles to get committed. But I really hope
that their cumulative effect can dramatically improve situation on high
number of connections. There are already some promising benchmarks in CSN
thread. I wonder if we already can do some cumulative benchmarks of
threads + CSN?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2017-12-08 22:42:13 Re: CUBE seems a bit confused about ORDER BY
Previous Message legrand legrand 2017-12-08 22:25:49 Re: Partition pruning for Star Schema