Helen,

I'm sorry if I wasn't clear enough. I'm not concerned with the
executable size, or how much data the DBMS can maintain. I'm
concerned with how much main memory the DBMS/database server requires
while running - not including the cached data in main memory that's
used speed up database operations.

Helen, you said it'd be good to know what I'm doing to answer my
questions. Well I have a single un-dedicated computer running many
applications on it that will be collecting sensory data from devices
connected to the motherboard. Because the DBMS will not be the only
thing running on the computer, the DBMS must have a small memory
footprint. I am hoping it won't use more than 200MB, or 500MB
including some cache space. Since I am not a database admin or
expert, I don't know what typical database server cache sizes are, so
I don't know how much extra main memory is required to get good
performance. So anyway, these devices push ~100KB messages to my
application with the embedded database (maybe firebird) every 10-100
milliseconds. It would probably be best to cache these in my
application and do a batch insert into the database. I will not allow
the database to automatically do this caching clients on the LAN will
connect to this application (NOT the database server itself) in order
to retrieve data. I am running a single dual-core with 2GB of memory.
Yes, I know it's not much. A candidate DBMS must be able to store
32GB of memory on my SSD.

Helen, I realize that the superserver and the classic are two
different models more or less of the same database server. You said
that the superserver creates threads for each connection and for
database housecleaning operations. To me that sounds like the
superserver WOULD be able to make use of a multi-core computer. And
you said that the classic model creates a new PROCESS for each
connection, which sounds like the less efficient model for a
multi-core since threads are more lightweight than processes.

I would appreciate it if you could clarify what you mean or correct me.

Thanks again,
Julian

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 11:06 9/10/2008, you wrote:
> >Hi all,
> >
> >I'm looking to evaluate firebird. I am requiring a really lightweight
> >database (running hopefully under 200MB, not including the cache in
> >main memory).
>
> Database? or database server? The Firebird executable is ~ 2 Mb.
DataBASES can be terabytes in size.
>
>
> >I noticed that superserver can take advantage of my dualcore whereas
> >class cannot.
>
> You have that back to front. SS must NOT be allowed to affine to
more than one CPU. Classic - which runs as a separate process per
client connected - can affine to any available CPU. I'm afraid I
don't know what score is with dual-core CPUs in either case.
>
> >From the term "superserver" I assume that it is not a
> >lightweight database.
>
> SS is one MODEL of the server, while Classic is another. The
"super" part of the name means something similar to "supervisor", not
something similar to "Superman". :-) It runs a single process and
creates threads of itself as required for client connections (as well
as for background housecleaning operations).
>
> >Can you guys confirm/deny this?
>
> Some of the guys could, most of the girls could. ;-) Mind you, given
the average age of the girls around here is ~99, we're old enough to
know better than to "confirm or deny"....
>
> >What are some typical memory
> >footprints of each one (an actual number and units would be helpful).
>
> ...or to make assessments of capacity based on no information about
intended usage in deployment, either.
>
> Maybe the first thing to get clear in your head is that Firebird is
not a database. It is database SERVER software for client/server
usage. Client/server means network clients (applications) making
requests through an API for services that operate on databases.
Architecturally there are numerous ways to effect that. At the small,
tight, desktop end that could be running a stand-alone application on
a laptop with an embedded server. At the opposite end it could be Web
browser clients in a widely distributed network in a multi-tier
arrangement; and statistically, it would be just about anything in
between.
>
> So - "typical" gets down to asking about resource usage from people
who have deployed systems that are architecturally and functionally
similar to what you want to do...
>
> ./heLen
>