Re: Performance nightmare with dspam (urgent) (resolved)
От | Michael Stone |
---|---|
Тема | Re: Performance nightmare with dspam (urgent) (resolved) |
Дата | |
Msg-id | 20050606172740.GC19670@mathom.us обсуждение исходный текст |
Ответ на | Re: Performance nightmare with dspam (urgent) (resolved) (John A Meinel <john@arbash-meinel.com>) |
Список | pgsql-performance |
On Mon, Jun 06, 2005 at 10:52:09AM -0500, John A Meinel wrote: >pg_xlog benefits from being super fast. Because it has to be fully >synced before the rest of the data can be committed. Yes they are small, >but if you can make it fast, you eliminate that overhead. It also >benefits from having it's own spindle, because you eliminate the seek >time. (Since it is always appending) Eliminating the seeks is definately a win. >Anyway, my point is that pg_xlog isn't necessarily tiny. Many people >seem to set it as high as 100-200, and each one is 16MB. It's not the size of the xlog, it's the size of the write. Unless you're writing out a stripe size of data at once you're only effectively writing to one disk pair at a time anyway. (Things change if you have a big NVRAM cache to aggregate the writes, but you'd need a *lot* of transaction activity to exceed the 50MB/s or so you could get from the single raid1 pair in that scenario.) Mike Stone
В списке pgsql-performance по дате отправления: