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.
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@xxxxxxxxxxxxxx)
