From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pierre C <lists(at)peufeu(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Dave Crooke <dcrooke(at)gmail(dot)com>, Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: shared_buffers advice |
Date: | 2010-03-16 14:53:38 |
Message-ID: | 407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Mar 16, 2010 at 2:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Pierre C" <lists(at)peufeu(dot)com> writes:
>> Does PG issue checkpoint writes in "sorted" order ?
>
> No. IIRC, a patch for that was submitted, and rejected because no
> significant performance improvement could be demonstrated. We don't
> have enough information about the actual on-disk layout to be very
> intelligent about this, so it's better to just issue the writes and
> let the OS sort them.
Keep in mind that postgres is issuing writes to the OS buffer cache.
It defers fsyncing the files as late as it can in the hopes that most
of those buffers will be written out by the OS before then. That gives
the OS a long time window in which to flush them out in whatever order
and whatever schedule is most convenient.
If the OS filesystem buffer cache is really small then that might not
work so well. It might be worth rerunning those benchmarks on a
machine with shared buffers taking up all of RAM.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2010-03-16 16:18:19 | Re: GiST index performance |
Previous Message | Greg Stark | 2010-03-16 14:51:11 | Re: shared_buffers advice |