Re: help tuning queries on large database - Mailing list pgsql-performance

From David Lang
Subject Re: help tuning queries on large database
Date
Msg-id Pine.LNX.4.62.0601061717470.24461@qnivq.ynat.uz
Whole thread Raw
In response to Re: help tuning queries on large database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Fri, 6 Jan 2006, Tom Lane wrote:

> Date: Fri, 06 Jan 2006 18:47:55 -0500
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: peter royal <peter.royal@pobox.com>
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] help tuning queries on large database
>
> peter royal <peter.royal@pobox.com> writes:
>> So, my question is, is there anything I can do to boost performance
>> with what I've got, or am I in a position where the only 'fix' is
>> more faster disks? I can't think of any schema/index changes that
>> would help, since everything looks pretty optimal from the 'explain
>> analyze' output. I'd like to get a 10x improvement when querying from
>> the 'cold' state.
>
> I don't think you have any hope of improving the "cold" state much.
> The right way to think about this is not to be in the "cold" state.
> Check your kernel parameters and make sure it's not set to limit
> the amount of memory used for cache (I'm not actually sure if there
> is such a limit on Linux, but there definitely is on some other Unixen).

Linux doesn't have any ability to limit the amount of memory used for
caching (there are periodicly requests for such a feature)

David Lang

> Look around and see if you can reduce the memory used by processes,
> or even better, offload non-database tasks to other machines.
>
> Basically you need to get as much of the database as you can to stay
> in disk cache.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

pgsql-performance by date:

Previous
From: Harry Jackson
Date:
Subject: Re: help tuning queries on large database
Next
From: Michael Stone
Date:
Subject: Re: improving write performance for logging