Hi Martin,
On 12/27/2012 8:31 AM, Martin Gainty wrote:
so...why doesn't Postgres port to embedded systems?
IME, it requires lots of resources (the vast majority of embedded
systems are resource starved -- resources == $$ and when you are
selling things in volume, every penny saved adds up quickly!).
Lots of MIPS, lots of RAM -- even the code footprint is "significant".
OTOH, (again, IME) designing with the "relational table" construct
makes coding a very different experience! Already being biased
in favor of table-driven algorithms, I took this opportunity to
move all the "const" tables out of my executables and into the
DBMS (which takes a performance hit but keeps the code much more
mutable). I've gone so far as to hide the filesystem from the
applications -- objects that would have typically resided in
ad hoc files are now stored in structured tables (eliminates
the need to write lots of special parsers to be able to impose
structure on what would otherwise be unstructured "bytes")
so do you reduce CPU or IO when you take a java variable final int
foo=1; and insert foo as a const column in a table?
[For the most part, I don't use Java as most of my projects have
real-time constraints and the lack of determinism in Java blows
that out of the water]
My (original) comment above is meant to address taking tables
of constants out of code and moving them into the DBMS -- *fetching*
them at run-time and using them in their normal role AS IF they
had been hard-coded into the executable.
E.g., given a Julian day, most folks would convert it to a (month,day)
tuple using a table like:
days[] = {
31, /* Jan */
28, /* Feb */
31, /* Mar */
30, /* Apr */
...
31 /* Dec */
}
Instead of putting this table in the code as a const datum, I would
store it in the DBMS and retrieve it as/when needed for the conversion.
[This is a silly example but one that is easy to understand]
Among other things, it allows me to change the contents of the
table without having to release a new executable
[Again, this example is silly in this regard as January will *always*
have 31 days so there will never be a need to change that! OTOH, if
the table is used to determine how far to advance the timing of the
spark in an internal combustion engine with respect to engine RPM's,
then you *may* want to change/tweek that table at some time in the
future to obtain better performance or accommodate changes in the
manufacture of the engine -- without changing all the code that
*references* that table. If that table is embedded in the actual
executable, this isn't very easy.]
As far as my parsing comment is concerned...
The structure that a table can impart to the data that it represents
allows you to identify that data *once*, stuff it into the appropriate
fields and then never have to parse the raw data object again.
E.g., early email readers maintained the user's "mailbox" as a simple
ASCII text file. New messages were appended to the end of the file.
When it came time to enumerate the messages or find a particular
message, the program had to parse the ASCII text sequentially knowing
the form that a message took so that it could identify the start
(and end) of each individual message.
If you were handed that ASCII file and asked "How many messages does
this contain", you would have to parse the file sequentially, knowing
the format of mail messages (in detail!) and count them.
If, instead, you have a table called "mail" with fields called
"From", "To", "Date", "Body", etc. then it's easy to determine
how many messages you have (count) or locate the most recent message
from "Bob", etc. The application can concentrate on the service(s)
that it wants to provide instead of having to be encumbered with
the trivialities of parsing message formats.
[Parsers are rife with opportunity for coding errors -- especially
those coded ad hoc!]
--don
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
