Re: Built-in connection pooling

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: Built-in connection pooling
Дата
Msg-id CAB=Je-FnLDq=JOe8M_sTr42iAXPhbAOJTVB7qTD4xiT4fhaHQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: Built-in connection pooling
Список 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 по дате отправления: