Thread: Needed files - embedded postgres
Hello list, I'm working on a project which tries to run postgre as a embedded database. I'm know looking at start up scripts and initdb scripts. What are the necessary files for running initdb and running postgres as an embedded database? All binary files and their deps are already fixed so the question is more related to files like postgres.bki and such. Regards, Henrik
On fös, 2006-12-15 at 11:41 +0100, Henrik Zagerholm wrote: > Hello list, > I'm working on a project which tries to run postgre as a embedded > database. > > I'm know looking at start up scripts and initdb scripts. > > What are the necessary files for running initdb and running postgres > as an embedded database? > > All binary files and their deps are already fixed so the question is > more related to files like postgres.bki and such. I think you should first figure out if postgres is suitable as an embedded database. (depends on what exactly you mean by an embedded database of course). Postgres has been designed as a server, and lots of implementation details might not make sense in an embedded context. you might be better served by SQLite, or some other such library. gnari
Thats true and we have. With the amount of data we need to handle and the queries we need to execute the postgresql database is way better suited for our needs. SQLite do not have the functions we need anyways. It is also quite crash resistant with the WAL implementation. We still create the datafiles on raid devices and only keep the binaries on a DiskOnModule device. Cheers, Henrik 15 dec 2006 kl. 13:49 skrev Ragnar: > On fös, 2006-12-15 at 11:41 +0100, Henrik Zagerholm wrote: >> Hello list, >> I'm working on a project which tries to run postgre as a embedded >> database. >> >> I'm know looking at start up scripts and initdb scripts. >> >> What are the necessary files for running initdb and running postgres >> as an embedded database? >> >> All binary files and their deps are already fixed so the question is >> more related to files like postgres.bki and such. > > I think you should first figure out if postgres is suitable as > an embedded database. (depends on what exactly you mean by > an embedded database of course). > > Postgres has been designed as a server, and lots of > implementation details might not make sense in an embedded > context. you might be better served by SQLite, or some other > such library. > > gnari > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
Henrik Zagerholm <henke@mac.se> writes:
>> Postgres has been designed as a server, and lots of
>> implementation details might not make sense in an embedded
>> context. you might be better served by SQLite, or some other
>> such library.
> ... It is also quite crash resistant with the WAL implementation.
One of the reasons it's crash resistant is exactly that it's *not*
embedded, and thus not subject to corruption by application-side bugs.
That concern is what has caused the developers to have zero interest
in creating an embeddable variant.
regards, tom lane
I think I need to specify what I mean with embedded. Its not that we try to embed it into an application. It is just run from a flash disk and the datafiles are put on standard raid attached disks. Its an embedded device not an embedded application. :) Cheers, Henrik 15 dec 2006 kl. 16:30 skrev Tom Lane: > Henrik Zagerholm <henke@mac.se> writes: >>> Postgres has been designed as a server, and lots of >>> implementation details might not make sense in an embedded >>> context. you might be better served by SQLite, or some other >>> such library. > >> ... It is also quite crash resistant with the WAL implementation. > > One of the reasons it's crash resistant is exactly that it's *not* > embedded, and thus not subject to corruption by application-side bugs. > That concern is what has caused the developers to have zero interest > in creating an embeddable variant. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend
On fös, 2006-12-15 at 16:59 +0100, Henrik Zagerholm wrote: > I think I need to specify what I mean with embedded. > Its not that we try to embed it into an application. > It is just run from a flash disk and the datafiles are put on > standard raid attached disks. > > Its an embedded device not an embedded application. :) will you have concurrent connections? gnari
15 dec 2006 kl. 17:15 skrev Ragnar: > On fös, 2006-12-15 at 16:59 +0100, Henrik Zagerholm wrote: >> I think I need to specify what I mean with embedded. >> Its not that we try to embed it into an application. >> It is just run from a flash disk and the datafiles are put on >> standard raid attached disks. >> >> Its an embedded device not an embedded application. :) > > will you have concurrent connections? > Yes, but maximum 5 connections. > > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
tgl@sss.pgh.pa.us (Tom Lane) writes:
> Henrik Zagerholm <henke@mac.se> writes:
>>> Postgres has been designed as a server, and lots of
>>> implementation details might not make sense in an embedded
>>> context. you might be better served by SQLite, or some other
>>> such library.
>
>> ... It is also quite crash resistant with the WAL implementation.
>
> One of the reasons it's crash resistant is exactly that it's *not*
> embedded, and thus not subject to corruption by application-side bugs.
> That concern is what has caused the developers to have zero interest
> in creating an embeddable variant.
Except, it appears to me that Henrik is intending to embed it not in
the sense of being a "shared library with application," but rather in
being "mostly hidden from users."
It seems pretty reasonable to me to try to figure out a near-minimal
footprint for PostgreSQL where, for instance, you might:
a) Restrict TZ to GMT, and thereby eliminate most timezone data
b) Restrict character encodings to C/SQL_ASCII, so that most of the
encoding libraries in $PGHOME/lib/ could go away
c) Drop pgxs (it's "embedded" - no further components are to be
added) and #include files
I'm finding my "make install" of PG 8.2 is ~15.5MB in size on Linux;
if I trimmed out the above, that would probably cut the size of the
install roughly in half.
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://cbbrowne.com/info/rdbms.html
"No matter how much money you spend, you can't make a racehorse out of
a pig. You can, however, make an awfully fast pig."
-- An old saying about program efficiency
15 dec 2006 kl. 17:40 skrev Chris Browne: > tgl@sss.pgh.pa.us (Tom Lane) writes: >> Henrik Zagerholm <henke@mac.se> writes: >>>> Postgres has been designed as a server, and lots of >>>> implementation details might not make sense in an embedded >>>> context. you might be better served by SQLite, or some other >>>> such library. >> >>> ... It is also quite crash resistant with the WAL implementation. >> >> One of the reasons it's crash resistant is exactly that it's *not* >> embedded, and thus not subject to corruption by application-side >> bugs. >> That concern is what has caused the developers to have zero interest >> in creating an embeddable variant. > > Except, it appears to me that Henrik is intending to embed it not in > the sense of being a "shared library with application," but rather in > being "mostly hidden from users." > Now we are talking :) > It seems pretty reasonable to me to try to figure out a near-minimal > footprint for PostgreSQL where, for instance, you might: > a) Restrict TZ to GMT, and thereby eliminate most timezone data > b) Restrict character encodings to C/SQL_ASCII, so that most of the > encoding libraries in $PGHOME/lib/ could go away I'm using UNICODE but thats a good thing right :) > c) Drop pgxs (it's "embedded" - no further components are to be > added) and #include files > > I'm finding my "make install" of PG 8.2 is ~15.5MB in size on Linux; > if I trimmed out the above, that would probably cut the size of the > install roughly in half. Even though size matters(!) its not that much of an issue on my system as I'm using 256 MB memory modules :) I've got it running OK. Now I just have to figure out how I easily can get libs working. I'm having some problems with plsql.so and such. When I'm done I'll probably post it on the wiki somewhere if it wuld interest anyone. Cheers, > -- > (reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc")) > http://cbbrowne.com/info/rdbms.html > "No matter how much money you spend, you can't make a racehorse out of > a pig. You can, however, make an awfully fast pig." > -- An old saying about program efficiency > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/