On Apr 20, 2005, at 17:09, Dan Sugalski wrote:
>> Does your own ISAM interface also convert ISAM calls to the SQL
>> queries?
>
> Yes of course -- it has to, there's no other way to access Postgres.
Some server specific API?
>> If so, then it is also add overhead: make a call to the some wrapper,
>> which will generate SQL query and send it to the sever, which will
>> parse, plan and compile it and execute only after that. Desirable:
>> make a call, which will connect to the server and get row.
>
> Right. And, as I said, the overhead is ignorable. It just doesn't
> matter.
>
>> I didn't have any legacy application, which I need to move to the new
>> DB, I just need more simple and fast access.
>
> Then either use PostISAM or write your own wrapper code to present an
> ISAM interface.
>
> You really need to understand that there's *already* a lot of overhead
> involved in Postgres, or any other relational database. ACID
> guarantees aren't free. Compared to the costs involved in Postgres, as
> well as in any app that's using the ISAM interface, the extra costs in
> the wrapping are negligible.
>
> Bluntly, you're worrying about the wrong stuff. Just write the
> wrappers, prepare the SQL statements (hell, pregenerate them if you
> want -- they don't have to be created on the fly), and ignore the
> library until it ends up being worth worrying about. You'll be
> ignoring it for a very long time.
I see no reason to write another ISAM wrapper if it will not invent
anything new.
I understand, that there is already a lot of overhead, but Berkeley DB
also "provides strict ACID transaction semantics". Would you like to
say, that PostgreSQL will be faster on simple operations than Berkeley
DB?
Regards,
/Alexandre.