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
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 |