Re: requested shared memory size overflows size_t

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Wilcox <hungrytom(at)gmail(dot)com>, Bob Lunney <bob_lunney(at)yahoo(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: requested shared memory size overflows size_t
Date: 2010-06-16 20:53:52
Message-ID: 1276721410-sup-6820@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Excerpts from Tom Lane's message of lun jun 14 23:57:11 -0400 2010:
> Scott Carey <scott(at)richrelevance(dot)com> writes:
> > Great points. There is one other option that is decent for the WAL:
> > If splitting out a volume is not acceptable for the OS and WAL -- absolutely split those two out into their own partitions. It is most important to make sure that WAL and data are not on the same filesystem, especially if ext3 is involved.
>
> Uh, no, WAL really needs to be on its own *spindle*. The whole point
> here is to have one disk head sitting on the WAL and not doing anything
> else except writing to that file.

However, there's another point here -- probably what Scott is on about:
on Linux (at least ext3), an fsync of any file does not limit to
flushing that file's blocks -- it flushes *ALL* blocks on *ALL* files in
the filesystem. This is particularly problematic if you have pgsql_tmp
in the same filesystem and do lots of disk-based sorts.

So if you have it in the same spindle but on a different filesystem, at
least you'll avoid that extra fsync work, even if you have to live with
the extra seeking.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-06-16 21:19:06 Re: Parallel queries for a web-application |performance testing
Previous Message Pierre C 2010-06-16 20:40:49 Re: PostgreSQL as a local in-memory cache