Re: Simplified (a-la [G|N]DBM) DB access
От | Alexandre |
---|---|
Тема | Re: Simplified (a-la [G|N]DBM) DB access |
Дата | |
Msg-id | b6943c871552681cade1b673aec6b705@rambler.ru обсуждение исходный текст |
Ответ на | Re: Simplified (a-la [G|N]DBM) DB access (Dan Sugalski <dan@sidhe.org>) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: