On Wed, 13 Feb 2008, Bruce Momjian wrote:
Should this be summarized somewhere in our docs; just a few lines with
the tradeoffs, direct storage = cheaper, faster, SAN = more configurable?
I think it's kind of stetching the PostgreSQL documentation to be covering
that. It's hard to generalize
On Feb 15, 2008, at 3:55 PM, Dan Langille wrote:
We're using PostgreSQL 8.1.11 on AIX 5.3 and we've been doing some
playing around
with various settings. So far, we've (I say we, but it's another
guy doing the work) found
that open_datasync seems better than fsync. By how much, we have
n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 15 Feb 2008 16:55:45 -0500
Dan Langille <[EMAIL PROTECTED]> wrote:
> Our tests have been on a p550 connected to DS6800 array using pgbench.
>
> One nasty behaviour we have seen is long running commits. Initial
> thoughts connected
> them wi
We're using PostgreSQL 8.1.11 on AIX 5.3 and we've been doing some
playing around
with various settings. So far, we've (I say we, but it's another guy
doing the work) found
that open_datasync seems better than fsync. By how much, we have not
yet determined,
but initial observations are pro
On Feb 15, 2008, at 12:42 PM, Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 15 Feb 2008 12:37:10 -0600
Erik Jones <[EMAIL PROTECTED]> wrote:
(welll, forced
to) migrate to a new system with a sane drive configuration. The
old set up was done horribly by a sysadm
Greg Smith wrote:
On Fri, 15 Feb 2008, Peter Schuller wrote:
Or is it a matter of PostgreSQL doing non-direct I/O, such that
anything cached in shared_buffers will also be cached by the OS?
PostgreSQL only uses direct I/O for writing to the WAL; everything
else goes through the regular OS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 15 Feb 2008 12:37:10 -0600
Erik Jones <[EMAIL PROTECTED]> wrote:
>(welll, forced
> to) migrate to a new system with a sane drive configuration. The
> old set up was done horribly by a sysadmin who's no longer with us
> who set us up with a R
On Feb 15, 2008, at 12:06 PM, Josh Berkus wrote:
On Friday 15 February 2008 06:29, Greg Smith wrote:
PostgreSQL only uses direct I/O for writing to the WAL; everything
else
goes through the regular OS buffer cache unless you force it to do
otherwise at the OS level (like some Solaris setups
On Friday 15 February 2008 06:29, Greg Smith wrote:
> PostgreSQL only uses direct I/O for writing to the WAL; everything else
> goes through the regular OS buffer cache unless you force it to do
> otherwise at the OS level (like some Solaris setups do with
> forcedirectio).
Also, note that even wh
On Thu, 14 Feb 2008, Michael Lorenz wrote:
When offsetting up to about 90K records, the EXPLAIN ANALYZE is similar to the
following:
Limit (cost=15357.06..15387.77 rows=20 width=35) (actual time=19.235..19.276
rows=20 loops=1)
-> Index Scan using account_objectname on "object" o (cost=0.00
On Fri, 15 Feb 2008, Peter Schuller wrote:
Or is it a matter of PostgreSQL doing non-direct I/O, such that
anything cached in shared_buffers will also be cached by the OS?
PostgreSQL only uses direct I/O for writing to the WAL; everything else
goes through the regular OS buffer cache unless y
thanks, i posted in this listed because it was related to my previous query.
Anyway, I am able to achieve, with the help in this mailing list, what I
wanted but is there any way to further optimize this.
Thanks
CREATE OR REPLACE FUNCTION test ( t1 text ) RETURNS numeric AS $$
declare cmd1 text;
> PostgreSQL still depends on the OS for file access and caching. I
> think that the current recommendation is to have up to 25% of your
> RAM in the shared buffer cache.
This feels strange. Given a reasonable amount of RAM (let's say 8 GB
in this case), I cannot imagine why 75% of that would be e
On Fri, Feb 15, 2008 at 01:35:29PM +0100, Peter Schuller wrote:
> Hello,
>
> my impression has been that in the past, there has been a general
> semi-consensus that upping shared_buffers to use the majority of RAM
> has not generally been recommended, with reliance on the buffer cache
> instead be
Hello,
my impression has been that in the past, there has been a general
semi-consensus that upping shared_buffers to use the majority of RAM
has not generally been recommended, with reliance on the buffer cache
instead being the recommendation.
Given the changes that have gone into 8.3, in parti
15 matches
Mail list logo
