By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,541 Members | 1,476 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,541 IT Pros & Developers. It's quick & easy.

pgSql Memory footprint

P: n/a
Hi:

Can anyone provide a rough guesstimate on how much memory does fully
conigured, with all the services turned on pgSql database require?

I'm trying to make an estimate on how much memory would be required in
Flash and RAM to run pgSql database.

Thanks.

Ish...
Nov 11 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Friday 12 September 2003 20:43, Ish Ahluwalia wrote:
Hi:

Can anyone provide a rough guesstimate on how much memory does fully
conigured, with all the services turned on pgSql database require?

I'm trying to make an estimate on how much memory would be required in
Flash and RAM to run pgSql database.


Depends on how many users and what queries you are running. The less RAM you
have available, the more disk I/O there will be.

Can you give more details of what sort of system you are trying to build?
--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 11 '05 #2

P: n/a
On Friday 12 September 2003 20:43, Ish Ahluwalia wrote:
Hi:

Can anyone provide a rough guesstimate on how much memory does fully
conigured, with all the services turned on pgSql database require?

I'm trying to make an estimate on how much memory would be required in
Flash and RAM to run pgSql database.


Depends on how many users and what queries you are running. The less RAM you
have available, the more disk I/O there will be.

Can you give more details of what sort of system you are trying to build?
--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 11 '05 #3

P: n/a
In article <20********************@archonet.com>, de*@archonet.com
says...
On Friday 12 September 2003 20:43, Ish Ahluwalia wrote:
Hi:

Can anyone provide a rough guesstimate on how much memory does fully
conigured, with all the services turned on pgSql database require?

I'm trying to make an estimate on how much memory would be required in
Flash and RAM to run pgSql database.


Depends on how many users and what queries you are running. The less RAM you
have available, the more disk I/O there will be.

Can you give more details of what sort of system you are trying to build?

Hi Richard:

Thanks for the resply. We're looking to use pgSql in a embedded systems
environment especially for a telecom switch. Memory may not be that big
of a issue as we plan to have a reasonable size flash and decent RAM too
(64 to 128 Mb - which is a lot for embedded systems). The idea here is
to use the database as a way to store information for all the processes
that may be running. The memory footprint I was looking for relates to
the disk storage required to store the loadable module/or binary program
on the flash disk, and also some insight into RAM required to run the
databse. The configuration would be achieve highest speed with most
amount of reliability. Any rough estimate into worst case memory usage
will be very beneficial?

Thanks in advance.

Ish...
Nov 11 '05 #4

P: n/a
Ish Ahluwalia <ah*******@erinc.com> writes:
Thanks for the resply. We're looking to use pgSql in a embedded systems
environment especially for a telecom switch. Memory may not be that big
of a issue as we plan to have a reasonable size flash and decent RAM too
(64 to 128 Mb - which is a lot for embedded systems). The idea here is
to use the database as a way to store information for all the processes
that may be running.


You'd probably be happier with something like Berkeley DB. PG isn't
really designed for that sort of thing --- just to start with, you don't
want to point it at flash RAM as "disk" storage, because your flash RAM
life expectancy of ~10000 write cycles won't last long.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #5

P: n/a
Tom Lane wrote:
Ish Ahluwalia <ah*******@erinc.com> writes:

Thanks for the resply. We're looking to use pgSql in a embedded systems
environment especially for a telecom switch. Memory may not be that big
of a issue as we plan to have a reasonable size flash and decent RAM too
(64 to 128 Mb - which is a lot for embedded systems). The idea here is
to use the database as a way to store information for all the processes
that may be running.


You'd probably be happier with something like Berkeley DB. PG isn't
really designed for that sort of thing --- just to start with, you don't
want to point it at flash RAM as "disk" storage, because your flash RAM
life expectancy of ~10000 write cycles won't last long.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

------------------------------------------------------------------------

SPAM: REFERENCES (-6.6 points) Has a valid-looking References header
SPAM: IN_REP_TO (-3.3 points) Has a In-Reply-To header
SPAM: X_MAILING_LIST (-0.0 points) Has a X-Mailing-List header
Score Total: -9.9

Not that I think it is a good idea... But is there any way to reduce the
impact on a flash memory 'disk' by tweaking some PostgreSQL knobs in
usually unadvisable ways? Also, if you have an enormous amount of flash
memory, isn't that 10,000 writes more than 10.000 writes? I read
somewhere that flash disks try to 'spread out' the wear and tear over
all available 'cells' on the media. If the database was used mostly for
selects, with only seldom update/insert/delete, would this idea make
more sense? I understand that this particular application would not fit
that profile, but there may be others where a full-on SQL database might
be desirable, but that would have few data modifications.

Thanks!!

Ian
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 11 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.