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
