| From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
|---|---|
| To: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Performance nightmare with dspam (urgent) (resolved) |
| Date: | 2005-06-06 17:27:40 |
| Message-ID: | 20050606172740.GC19670@mathom.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Rinaudo | 2005-06-06 17:53:40 | Postgresql on an AMD64 machine |
| Previous Message | Tobias Brox | 2005-06-06 17:25:08 | Re: Need help to decide Mysql vs Postgres |