Thread: Re: Can postgresql be run in memory (like a memory resi
What I am trying to do is, I have multiple databases some of which are frequently accessed. So I am trying to see if the one's which are frequently accessed can be run as memory resident and others run normally. I am thinking this might improve response times. Thanks Ravi -----Original Message----- From: Andrew Perrin [mailto:clists@perrin.socsci.unc.edu] Sent: Tuesday, February 25, 2003 9:14 AM To: Malghan, Ravi Cc: 'pgsql-general@postgresql.org' Subject: Re: [GENERAL] Can postgresql be run in memory (like a memory resident program) What is it that you want to *do*? Like any program, while postgresql is running, parts of it are in memory. ap ---------------------------------------------------------------------- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill clists@perrin.socsci.unc.edu * andrew_perrin (at) unc.edu On Tue, 25 Feb 2003, Malghan, Ravi wrote: > Is it possible to run post-gresql in memory? I searched through all the > older postings didn't find much info. > > Thanks > Ravi > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
On Tue, Feb 25, 2003 at 09:59:16AM -0500, Malghan, Ravi wrote:
> frequently accessed. So I am trying to see if the one's which are frequently
> accessed can be run as memory resident and others run normally. I am
If you manage your shared buffers and filesystem buffers correctly,
that should happen automatically.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
If you are looking for performance I think letting the caching in the OS/PostgreSQL take care of keeping stuff in memory is your best bet. But make sure that you have given it a chance. Have you already adjusted the settings in postgresql.conf? The default is to severely limit the resources used by PostgreSQL so that it will at least start and run run on as many platforms as possible. It is not set by default to run as fast as possible. It is assumed (seemingly often incorrectly given the recent thread on changing the default configuration) that the administrator will adjust the settings as appropriate for the capacity/requirements of that specific installation. Cheers, Steve On Tuesday 25 February 2003 6:59 am, Malghan, Ravi wrote: > What I am trying to do is, I have multiple databases some of which are > frequently accessed. So I am trying to see if the one's which are > frequently accessed can be run as memory resident and others run normally. > I am thinking this might improve response times.
Quoth rmalghan@btspartners.com ("Malghan, Ravi"):
> What I am trying to do is, I have multiple databases some of which
> are frequently accessed. So I am trying to see if the one's which
> are frequently accessed can be run as memory resident and others run
> normally. I am thinking this might improve response times.
In the ancient past, people would "set the sticky bit" on executable
programs to force them to stay in memory; that idea has become
obsolete what with larger memory sizes and more sophisticated memory
management schemes in Unix variants. I think you're essentially
trying to express the same idea here...
The tables/databases that are frequently accessed should already be
mostly in memory as a result of the way your OS caches data.
It's not likely that there's anything that you can do "inside
PostgreSQL" that would be helpful in this regard.
--
output = ("cbbrowne" "@acm.org")
http://cbbrowne.com/info/finances.html
"Though the Chinese should adore APL, it's FORTRAN they put their
money on." -- Alan Perlis
On Tue, 2003-02-25 at 15:11, Christopher Browne wrote: > The tables/databases that are frequently accessed should already be > mostly in memory as a result of the way your OS caches data. > > It's not likely that there's anything that you can do "inside > PostgreSQL" that would be helpful in this regard. Strictly speaking, there's plenty you could do inside PostgreSQL to improve caching. Database access patterns tend to be quite different from other types of I/O workloads, so designing buffer replacement policies to account for this has been widely shown to offer better performance than more generic algorithms such as LRU or GClock (for example, the LRU-K and 2Q algorithms). Furthermore, the database system itself knows more than the kernel does about the type of workload that is being executed. For example, this type of knowledge might allow a database system to avoid the eviction of hot pages from the buffer during a large sequential scan. However, PostgreSQL currently does little of that, and just depends on the kernel to handle most buffering. There are good reasons for that, though. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC