Small OS ports & Handheld devices - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Small OS ports & Handheld devices |
Date | |
Msg-id | 1083276855.3100.282.camel@stromboli Whole thread Raw |
Responses |
Re: Small OS ports & Handheld devices
Re: Small OS ports & Handheld devices |
List | pgsql-hackers |
Seemingly completely opposite to my usual focus on large scale enterprise issues and requirements, I'm looking into PostgreSQL on small handheld devices. Clearly these have limited memory and little "disk" capability... Are there some ports available to various devices? What is the lowest memory footprint PostgreSQL has achieved? [8Mb was last quote] How little disk space has anyone achieved? Is that an available port, or just a set of configure options? Is there a definitive list of supported ports? (for anything) Does PostgreSQL run on? - Windows 2003 (is that part of Win32 port as a defined target?) - PalmOS - Zaurus Related info is copied below: Q: Does PostgreSQL write repeatedly even when there is a no overt SQL write activity? With a write-capable, but very low write rate, PostgreSQL seems a good candidate, given current memory capacities? Dredging up last year's discussion on "postgres on a PDA" we have.. "Al Bean" <albean84 ( at ) hotmail ( dot ) com> writes: > My PDA has 32MB of RAM (well more like 16 with the way Sharp allocates it) > and I use a 256MB FLASH memory card which sort of looks like a hard drive on > the PDA. I know postgresql will run in about 8MB of RAM so I think I should > be ok on this front but I'm wondering about the data residing in > FLASH. Postgres has kind of gotten away from the notion of a small disk footprint :-(. Some things to look at: * Definitely reduce the size of WAL segments (see XLogSegSize). You can't afford the default 16MB. * You probably don't want to have multiple databases. I'd suggest doing all your work in template1. Consider also dropping template0 --- its only value would be to reinit template1, and if you need to do that you might as well re-initdb. But I fear the real problem is going to be that FLASH memory has a limited lifetime (measured in write cycles). Postgres is going to spend that lifetime with abandon, because it has absolutely no motivation to avoid disk writes. Are you prepared to replace the FLASH every so often? ..reply... In article <1883 ( dot ) 1042606899 ( at ) sss ( dot ) pgh ( dot ) pa ( dot ) us>, Tom Lane <tgl ( at ) sss ( dot ) pgh ( dot ) pa ( dot ) us> wrote: >attention I think it was on the order of magnitude of 10000 write >cycles --- which Postgres could blow through in no time. I hope >it's better now, but I dunno by how much. Anyone have more >up-to-date info? Only about 1 order of magnitude better. From the Linux Embedded FAQ: Q: 3.3 Flash Limited write cycles Flash have limited write cycles capabilities from 200 000 to 400 000. Using swap on such device is dangerous. 300 000writes gives you 200 days at 1 write / minute and 83 hours at 1 write / second. More, If you interrupt power at arbitrarytimes while the device is writing, you can lose the integrity of the file system being modified. The loss is notlimited to the 512 byte sector being modified, as it generally is with rotating disks; you can lose an entire eraseblock, maybe 64K at once. The risk goes up as the "disk" approaches full, because erase rewrite cycles happen moreoften in this condition. Un*x file systems spread their super block tables around the "disk", in the hope that at least one will survive a head crash. Create one file, then /bin/sync: what percentage of the device's erase blocks get hit? Thanks, Simon Riggs 2nd Quadrant
pgsql-hackers by date: