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
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 |