On Wed, 2010-01-06 at 16:39 +0100, Adrian von Bidder wrote:
> Howdy!
>
> I'm currently in a MySQL -> PostgreSQL migration project (Go, go, go, ...
> shall I cc: slashdot, too? ;-)
>
> Part of this is in embedded context, where a (diskless) embedded computer
> runs from flash. Since we don't want to stress the flash too much, the db
> is actually loaded from a dump at boot and run off a ramdisk (and dumped
> back to flash periodically.)
>
> So all the nice database crash-safety that pg offers goes down the drain...
>
> With this in mind: what can we tune to minimize diskspace (RAM-disk space)
> usage? And, possibly, RAM usage as well (disk access is, after all, almost
> as fast as RAM access in this scenario)
>
> With our test dump, the db (after import) is ca. 300M on disk, ca. half in
> WAL files (pg_xlog.) If I could mostly get rid of the WAL (keep it to a
> bare minimum and run pg without fsync, something like that), the remaining
> 160 to 180M would be ok.
>
> Next thing would be: are there tunables (compile time?) to minimize the
> actual size of the rows?
>
> Your input is valued, thanks in advance.
Wow, here are some things but honestly Pg may not be the DB you are
looking for.
You can set checkpoint_segments to 3. That will use 48 megs at any given
time but will force a checkpoint (likely quite a few) during your load.
This will slow the load down.
As far as rows... there isn't really anything you can do. The data and
its representation is the data.
I thoroughly applaud your willingness to move to Pg but in this case
something like SQLite or even Ingres may be a better solution for you.
Sincerely,
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.