| From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Medi Montaseri <medi(dot)montaseri(at)intransa(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Buffer Cache question.... |
| Date: | 2003-04-30 21:09:52 |
| Message-ID: | Pine.LNX.4.33.0304301508380.19726-100000@css120.ihs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 30 Apr 2003, Bruce Momjian wrote:
> Medi Montaseri wrote:
> > I am using PG 7.2 with fsync truned on but still need a more immediate
> > write thru.
> > Does PG uses the fsync (or open_sync, etc) just for the WAL or for
> > tables as well ?
>
> Just for WAL.
>
> > I understand the consequence of limiting buffer cache but my application
> > cares more about
> > integrity than performance. I'd like to be able to write the data to the
> > physical storage ASAP,
> > or ideally 100% in sync mode.
> >
> > I have found that by reducing the checkpoint parameters I can write the
> > data to disk sooner.
> > For example
> >
> > checkpoint_segments = 1
> > checkpoint_timeout = 30
> >
> > What else do I have to work with....?
>
> PostgreSQL is already 100% reliable (pull plug and see) so I don't see
> any value to changing those parameters.
What about commit_siblings and commit_delay? I haven't really played a
lot with those. I would think increasing the commit delay and the number
of siblings should give better, but slightly bursty performance.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | btober | 2003-04-30 21:20:23 | Querying the last value of all sequences |
| Previous Message | Stephan Szabo | 2003-04-30 20:57:24 | Re: check_foreign_key |