| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 2018-03 Commitfest Summary (Andres #1) |
| Date: | 2018-03-04 01:56:28 |
| Message-ID: | CAMsr+YGrgT4ngULSgyjpGzkffBwMJxCCRpxS2vP67V+7HYHMFg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2 March 2018 at 17:47, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> For instance, I used extensively tps throttling, latencies and timeouts
> measures when developping and testing the checkpointer sorting & throttling
> patch.
>
I have to admit, I've found tps throttling and latency measurement useful
when working with logical replication. It's really handy to find a stable,
sustainable throughput on master at which a replica can keep up.
PostgreSQL is about more than raw TPS. Users care about latency. Things we
change affect latency. New index tricks like batching updates; sync commit
changes for standby consistency, etc.
That's not a reason to throw anything and everything into pgbench. But
there's value to more than measuring raw tps.
Also, I'm not the one doing the work.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2018-03-04 02:09:39 | Re: 2018-03 Commitfest Summary (Andres #1) |
| Previous Message | Craig Ringer | 2018-03-04 01:49:35 | Re: 2018-03 Commitfest Summary (Andres #1) |