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:
Show quoted text
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
Show quoted text
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