Re: Built-in connection pooling - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: Built-in connection pooling
Date
Msg-id CAB=Je-FnLDq=JOe8M_sTr42iAXPhbAOJTVB7qTD4xiT4fhaHQg@mail.gmail.com
Whole thread Raw
In response to Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List 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

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Lockable views
Next
From: Peter Eisentraut
Date:
Subject: Re: Cancelling parallel query leads to segfault