Re: Commitfest remaining "Needs Review" items

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: Commitfest remaining "Needs Review" items
Date: 2015-08-25 09:05:44
Message-ID: alpine.DEB.2.10.1508251047100.14257@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> -- merging pgbench logs: returned with feedback or bump? Fabien has
> concerns about performance regarding fprintf when merging the logs.
> Fabien, Tomas, thoughts?
> -- pgbench - per-transaction and aggregated logs: returned with
> feedback or bump to next CF? Fabien, Tomas, thoughts?

I think that both features are worthwhile so next CF would be better, but
it really depends on Tomas.

The key issue was the implementation complexity and maintenance burden
which was essentially driven by fork-based thread emulation compatibility,
but it has gone away as the emulation has been taken out of pgbench and it
is now possible to do a much simpler implementation of these features.

The performance issue is that if you have many threads which perform
monstruous tps and try to log them then logging becomes a bottle neck,
both the "printf" time and the eventual file locking... Well, that is
life, it is well know that experimentators influence experiments they are
looking at since Schrödinger, and moreover the --sampling-rate option is
already here to alleviate this problem if needed, so I do not think that
it is an issue to address by keeping the code complex.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-08-25 09:18:54 Re: Planned release for PostgreSQL 9.5
Previous Message Simon Riggs 2015-08-25 08:51:10 Re: Reducing ClogControlLock contention