Re: Enough RAM for entire Database.. cost aside, is this

From: Mike Rylander <miker(at)purplefrog(dot)com>
To: Andy B <abhousehuntRE-M--O--V-E(at)blueyonder(dot)co(dot)uk>
Subject: Re: Enough RAM for entire Database.. cost aside, is this
Date: 2004-07-02 14:20:12
Message-ID: cc3rt0$22kv$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

<posted & mailed>

Andy B wrote:

> Hello Shridhar,
>
> Thanks for the reply.
>
>> There is no reason why you should not do it. How remains to be a point of
>> disagreement though. You don't allocate 16GB of shared buffers to
> postgresql.
>> That won't give you performance you need.
>
> I think in the other thread, Tom was alluding to this too. What is it
> about the shared buffer cache behaviour that makes it inefficient when it
> is very large? (assuming that the address space it occupies is allocated
> to RAM pages)

It's not that making the cache bigger is inefficient, it's that the cache is
not used the way you are thinking. Postgres does not try to create its own
large persistent cache of recently used data, because the OS (especially
Linux, and especially on an Opteron and compiled for 64 bit) is really much
better at caching. In fact, other that herding programs and implementing
security, optimizing the use of resources is what the OS is for.

>
> Is there a good place I could look for some in depth details of its
> behaviour?

There's a good bit of depth in the archives of this list. I would start
searching back for discussions of effective_cache_size, as that is involved
in *costing* the caching job that the OS is doing.

>
> Many thanks,
> Andy

--miker

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Maus 2004-07-02 14:27:33 how could I connect a Postgres database in c language using odbc?
Previous Message Michal Taborsky 2004-07-02 14:11:22 Row-level security--is it possible?