Re: [HACKERS] ARC Memory Usage analysis - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] ARC Memory Usage analysis
Date
Msg-id 20651.1098720192@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] ARC Memory Usage analysis  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: [HACKERS] ARC Memory Usage analysis
List pgsql-patches
Jan Wieck <JanWieck@Yahoo.com> writes:
> This all only holds water, if the OS is allowed to swap out shared
> memory. And that was my initial question, how likely is it to find this
> to be true these days?

I think it's more likely that not that the OS will consider shared
memory to be potentially swappable.  On some platforms there is a shmctl
call you can make to lock your shmem in memory, but (a) we don't use it
and (b) it may well require privileges we haven't got anyway.

This has always been one of the arguments against making shared_buffers
really large, of course --- if the buffers aren't all heavily used, and
the OS decides to swap them to disk, you are worse off than you would
have been with a smaller shared_buffers setting.


However, I'm still really nervous about the idea of using
effective_cache_size to control the ARC algorithm.  That number is
usually entirely bogus.  Right now it is only a second-order influence
on certain planner estimates, and I am afraid to rely on it any more
heavily than that.

            regards, tom lane

pgsql-patches by date:

Previous
From: Kenneth Marshall
Date:
Subject: Re: [HACKERS] ARC Memory Usage analysis
Next
From: "Matthew T. O'Connor"
Date:
Subject: pg_autovacuum vacuum cost variables patch