On Aug 3, 2006, at 1:26 PM, Merlin Moncure wrote:
On 8/2/06, Thomas F. O'Connell <[EMAIL PROTECTED]> wrote:
I'm working on a postgres instance (8.1.2 running on Solaris 10)
where the
data directory (including WAL) is being mounted on tmpfs. Based on
this, and
with knowledge that fsync is disabled, I'm operating under the
assumption
that recoverability is not a precondition for optimized
performance. With
that assumption, I have several questions, some performance-
related, others
internals-related:
to be honest, I think the best approach is to simply write to the
traditional filesystem and leave fsync off. writing to a ramdisk
might be a bit faster, but you deprive the server memory from doing
other things like caching and sorting. this might be more true for
some o/s than others though. i'm just curious, what led you to do
ramdisk implementation (most people who ask questions about ramdisk
have no idea what they are talking about, although you seem to).
That was how I found it. :)
I think, though, that it was the result of benchmarking a variety of
on-disk RAID configurations with an eye toward ever increasing write
throughput.
4. Considering that recoverability is not a precondition, is there
an easy
patch that could be applied to the 8.1.x series from 8.1.4 on that
would
allow disabling full_page_writes? For a database in RAM with high
write
volume, is this setting even likely to make a difference?
I would suggest pulling 8.2dev (shortly beta) if you want this and
experiment. it is perfectly stable. looking at the todo list, 8.2
also gets the multiple insert syntax, which is nice.
if have super high write volumes, consider writing your insert call in
C. prepare your statement, and use the parameterized
version....ExecPrepared(...).
Can you point to a good example of this anywhere in the docs? I don't
see ExecPrepared anywhere in the core documentation.
--
Thomas F. O'Connell
Sitening, LLC
http://www.sitening.com/
3004B Poston Avenue
Nashville, TN 37203-1314
615-469-5150 x802
615-469-5151 (fax)
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
