Обсуждение: pgSql Memory footprint
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...
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
In article <200309132112.45526.dev@archonet.com>, dev@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...
Ish Ahluwalia <ahluwalia@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
Tom Lane wrote: >Ish Ahluwalia <ahluwalia@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