Re: Built-in connection pooling

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Built-in connection pooling
Date: 2018-02-01 20:28:33
Message-ID: CAB=Je-FnLDq=JOe8M_sTr42iAXPhbAOJTVB7qTD4xiT4fhaHQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> config/pgjsonb-local.dat

Do you use standard "workload" configuration values?
(e.g. recordcount=1000, maxscanlength=100)

Could you share ycsb output (e.g. for workload a)?
I mean lines like
[TOTAL_GC_TIME], Time(ms), xxx
[TOTAL_GC_TIME_%], Time(%), xxx

>postgresql-9.4.1212.jar

Ok, you have relevant performance fixes then.

Konstantin>Just simple example: consider that you have something like
AppStore and there is some popular application which is bought by a lot of
users.
Konstantin>From DBMS point of view a lot of clients perform concurrent
update of the same record.

I thought YCSB updated *multiple rows* per transaction. It turns out all
the default YCSB workloads update just one row per transaction. There is no
batching, etc. Batch-related parameters are used at "DB initial load" time
only.

Konstantin>Postgres locks tuples in very inefficient way in case of high
contention

Thank you for the explanation.

Vladimir

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-02-01 20:33:49 Re: Re: BUG #15039: some question about hash index code
Previous Message Robert Haas 2018-02-01 20:16:13 Re: [HACKERS] [PATCH] Lockable views