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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-performance(at)postgresql(dot)org, gnuoytr(at)rcn(dot)com
Subject: Re: How does PG know if data is in memory?
Date: 2010-10-13 06:40:40
Message-ID: AANLkTinPNkMeJKX2=TdB4UD6gYScjn1=+5uP2O4C+F3h@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Oct 12, 2010 at 10:35 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> (1) Heavily used data could be kept fully cached in RAM and not
> driven out by transient activity.

We've attempted to address this problem by adding logic to prevent the
buffer cache from being trashed by vacuums, bulk loads, and sequential
scans. It would be interesting to know if anyone has examples of that
logic falling over or proving inadequate.

> (2) You could flag a cache used for (1) above as using "relaxed LRU
> accounting" -- it saved a lot of time tracking repeated references,
> leaving more CPU for other purposes.

We never do strict LRU accounting.

> (3) Each named cache had its own separate set of locks, reducing
> contention.

We have lock partitions, but as discussed recently on -hackers, they
seem to start falling over around 26 cores. We probably need to
improve that, but I'd rather do that by making the locking more
efficient and by increasing the number of partitions rather than by
allowing users to partition the buffer pool by hand.

> (4) Large tables for which the heap was often were scanned in its
> entirety or for a range on the clustered index could be put in a
> relatively small cache with large I/O buffers.  This avoided blowing
> out the default cache space for situations which almost always
> required disk I/O anyway.

I think, but am not quite sure, that my answer to point #1 is also
relevant here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2010-10-13 06:45:16 Re: Slow count(*) again...
Previous Message Ron Mayer 2010-10-13 03:16:25 Re: How does PG know if data is in memory?