Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id CA+TgmobJqaO9YzAbuh35a_wQfQuybPJYucxWM5FaSxWvAU3dCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Vladimir Borodin <root@simply.name>)
Список pgsql-hackers
On Fri, Sep 18, 2015 at 4:43 PM, Vladimir Borodin <root@simply.name> wrote:
> No, probably you misunderstood the results, let me explain one more time.

Yeah, I did, sorry.

> Unpatched PostgreSQL from REL9_4_STABLE gave 15500 tps. Version with timings
> - 14500 tps which is 6,5% worse. Version with sampling wait events every 10
> ms gave 13800 tps (11% worse than unpatched and 5% worse than with timings).

OK.

So, I don't really care about the timing stuff right now.  I want to
get the stuff without timings done first.  To do that, we need to come
to an agreement on how much information we're going to try to expose
and from where, and we need to make sure that doing that doesn't cause
a performance hit.  Then, if we want to add timing as an optional
feature for people who can tolerate the overhead, that's fine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Speed up Clog Access by increasing CLOG buffers
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Limit GIST_MAX_SPLIT_PAGES to XLR_MAX_BLOCK_ID