Thanks, everyone, for your comments.
I guess if something looks too good to be true then it usually is!
Steven.
(P.S. Apologies for the email disclaimer - it is added by our mail server, not
my mail client, and its exclusion list is on the fritz)
Hi,
On 2019-05-07 10:32:45 -0700, Andres Freund wrote:
> pgbench -i -q -s 96 && pgbench -n -c 8 -j 8 -T 100 -P1
possibly also worthwhile to note: Adding -M prepared (which I think
phoronix doesn't specify) makes this considerably faster...
Greetings,
Andres Freund
Hi,
On 2019-05-07 10:28:16 -0700, Peter Geoghegan wrote:
> On Tue, May 7, 2019 at 10:06 AM Tom Lane wrote:
> > Given the described test setup, I'd put basically no stock in these
> > numbers. It's unlikely that this test case's performance is CPU-bound
> > per se; more likely, I/O and lock
Hi,
On 2019-05-07 16:14:43 +, Steven Winfield wrote:
> (Apologies if this isn't the right place to post this)
Seems right.
> A few days ago a blog post appeared on phoronix.com[1] comparing GCC 8.3.0
> against 9.0.1 on Intel cascadelake processors.
> A notable difference was seen in the
On Tue, May 7, 2019 at 10:06 AM Tom Lane wrote:
> Given the described test setup, I'd put basically no stock in these
> numbers. It's unlikely that this test case's performance is CPU-bound
> per se; more likely, I/O and lock contention are dominant factors.
> So I'm afraid whatever they're
Steven Winfield writes:
> A few days ago a blog post appeared on phoronix.com[1] comparing GCC 8.3.0
> against 9.0.1 on Intel cascadelake processors.
> A notable difference was seen in the PostgreSQL benchmark (v10.3, pgbench,
> read/write, more detail below), both when compiling with
Hi,
(Apologies if this isn't the right place to post this)
A few days ago a blog post appeared on phoronix.com[1] comparing GCC 8.3.0
against 9.0.1 on Intel cascadelake processors.
A notable difference was seen in the PostgreSQL benchmark (v10.3, pgbench,
read/write, more detail below), both
