Re: LWLOCK_STATS

From: Jim Nasby <jim(at)nasby(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LWLOCK_STATS
Date: 2012-01-11 23:29:27
Message-ID: C433FB46-02CD-4B54-830F-36F2CC2C891E@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan 10, 2012, at 3:16 AM, Simon Riggs wrote:
> On Tue, Jan 10, 2012 at 12:24 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> IIRC, pg_bench is *extremely* write-heavy. There's probably not that many systems that operate that way. I suspect that most OLTP systems read more than they write, and some probably have as much as a 10-1 ratio.
>
> IMHO the main PostgreSQL design objective is doing a flexible, general
> purpose 100% write workload. Which is why Hot Standby and
> LISTEN/NOTIFY are so important as mechanisms for offloading read
> traffic to other places, so we can scale the total solution beyond 1
> node without giving up the power of SQL.

There's a problem with that theory though... in an actual OLTP system it can be extremely difficult to effectively split read and write workloads unless you've got some really easy way to know that you're not reading data that was just modified. I realize that there are caching and some other tricks that can help here, but AFAICT they all have some pretty significant drawbacks that can easily limit where they can be used.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-01-11 23:32:59 Remembering bug #6123
Previous Message Simon Riggs 2012-01-11 23:13:20 Re: [WIP] Double-write with Fast Checksums