Re: Commitfest Status: Sudden Death Overtime

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Commitfest Status: Sudden Death Overtime
Date: 2011-07-19 04:41:04
Message-ID: 1311050464.31101.31.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2011-07-18 at 15:59 -0400, Robert Haas wrote:
> On a pgbench run with 8
> clients on a 32-core machine, I see about a 2% speedup from that patch
> on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but
> still just a 32-core box), the results bounce around more, but taking
> the median of three five-minute runs, it's an 11% improvement. To me,
> that's enough to make it worth applying, especially considering that
> what is 11% on today's master is, in raw TPS, equivalent to maybe 30%
> of yesterday's master (prior to the fast relation lock patch being
> applied). More, it seems pretty clear that this is the conceptually
> right thing to do, even if it's going to require some work elsewhere
> to file down all the rough edges thus exposed. If someone objects to
> that, then OK, we should talk about that: but so far I don't think
> anyone has expressed strong opposition: in which case I'd like to fix
> it up and get it in.

Agreed. I certainly like the concept of the lazy vxid patch.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-07-19 05:08:46 Re: pg_upgrade and log file output on Windows
Previous Message Peter Eisentraut 2011-07-19 04:24:15 Re: Avoid index rebuilds for no-rewrite ALTER TABLE ALTER TYPE