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:

Previous
From: Tom Lane
Date:
Subject: Re: Call for 7.5 feature completion
Next
From: Tom Lane
Date:
Subject: Re: Small OS ports & Handheld devices