Re: How does PG know if data is in memory?

From: Samuel Gendler <sgendler(at)ideasculptor(dot)com>
To: Fabrício dos Anjos Silva <fabricio(dot)silva(at)linkcom(dot)com(dot)br>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: How does PG know if data is in memory?
Date: 2010-09-29 17:08:39
Message-ID: AANLkTik5hnOcU=spN0wmWmR6_wHN=sKfVNzJeDuPTVW_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

2010/9/29 Fabrício dos Anjos Silva <fabricio(dot)silva(at)linkcom(dot)com(dot)br>

>
>
> When setting seq_page_cost and random_page_cost, do I have to consider
> the probability that data will be in memory? Or does seq_page_cost mean
> "sequential access on disk" and random_page_cost mean "random access on
> disk"?
>
>
The reason seq_page_cost and random_page_cost exist as parameters is so that
you can inform the optimizer what the relative costs of those actions are,
which is directly related to the expected size of the filesystem cache,
ratio of total db size to available cache memory, and the performance of
your disk i/o subsystems (and any other disk-related work the host may be
doing). effective_cache_size allows you to tell postgres how big you
believe all available cache memory is - shared_buffers and OS cache.

As to your question about increasing shared_buffers to be some significant
proportion of available RAM - apparently, that is not a good idea. I've
seen advice that said you shouldn't go above 8GB for shared_buffers and I've
also seen 12GB suggested as an upper limit, too. On my host with 48GB of
RAM, I didn't see much difference between 8GB and 12GB on a fairly wide
variety of tests, so mine is set at 8GB with an efective_cache_size of 36GB.

> I appreciate if someone could clear this out.
>
> Thanks!
>
> Fabrício dos Anjos Silva
> LinkCom Soluções em T.I.
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-09-29 21:00:39 Re: Wrong index choice
Previous Message Fabrício dos Anjos Silva 2010-09-29 16:55:26 Wrong index choice