Re: LWLOCK_STATS

Поиск
Список
Период
Сортировка
Искать
От
Jim Nasby
Тема
Re: LWLOCK_STATS
Дата
Msg-id
C433FB46-02CD-4B54-830F-36F2CC2C891E@nasby.net
Ответ на
Re: LWLOCK_STATS (Simon Riggs)
Список
Дерево обсуждения
LWLOCK_STATS Robert Haas <robertmhaas@gmail.com>
Re: LWLOCK_STATS Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: LWLOCK_STATS Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLOCK_STATS Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: LWLOCK_STATS Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: LWLOCK_STATS "Satoshi Nagayasu / Uptime Technologies, LLC." <snaga@uptime.jp>
Re: LWLOCK_STATS Simon Riggs <simon@2ndQuadrant.com>
Re: LWLOCK_STATS Robert Haas <robertmhaas@gmail.com>
Re: LWLOCK_STATS Jeff Janes <jeff.janes@gmail.com>
Re: LWLOCK_STATS Robert Haas <robertmhaas@gmail.com>
Re: LWLOCK_STATS Jim Nasby <jim@nasby.net>
Re: LWLOCK_STATS Robert Haas <robertmhaas@gmail.com>
Re: LWLOCK_STATS Simon Riggs <simon@2ndQuadrant.com>
Re: LWLOCK_STATS Jim Nasby <jim@nasby.net>
Re: LWLOCK_STATS Merlin Moncure <mmoncure@gmail.com>
On Jan 10, 2012, at 3:16 AM, Simon Riggs wrote:
> On Tue, Jan 10, 2012 at 12:24 AM, Jim Nasby  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@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-hackers по дате отправления
От: Simon Riggs
Дата:
От: Kevin Grittner
Дата:
Сообщение: Remembering bug #6123
FAQ