Re: Alternative new libpq interface.
| От | Chris Bitmead |
|---|---|
| Тема | Re: Alternative new libpq interface. |
| Дата | |
| Msg-id | 396AB592.F6288405@nimrod.itg.telecom.com.au обсуждение исходный текст |
| Ответ на | Re: Alternative new libpq interface. (M.Feldtmann@t-online.de (Marten Feldtmann)) |
| Ответы |
Re: Alternative new libpq interface.
|
| Список | pgsql-hackers |
Marten Feldtmann wrote: > Hmmm, what you want is not that easy. It means, that the object > data is stored several times on the client: > > - you MUST hold an independent cache for each open connection > to the database. > - you MUST copy the values from the cache to the language > dependent representation. No it's stored once on the client. The language dependant cache IS the cache. > And you still do not get the result you want to have: the > integrity problem. What happens, if the cache is not big > enough. How are cached objects thrown away ? Garbage Collector > in the cache system ?? The most simple scenario is that all objects are discarded upon transaction commit. Beyond that, there are other scenarios. Like if you want to reclaim some cache then UPDATE the database with any changes and leave the transaction open. If you need an object again then you read it in again. But to a large extent, memory management is based on the model of the programming language that you use, and managing it properly. Even if you use JDBC you can't just slurp gigabytes into memory. You have to re-use memory according to the conventions of the language in use. > And another point: this has nothing to do with an ODMG interface. > It's just a nice performance hint for database access, but > ODMG has nothing to do with it. What has nothing to do with ODMG? > Normally the identity is assured by the language binding - either > by the database (as you would like it) or by the binding of a > particular language to this database. > > To get an ODMG language binding you may use the libpq. You may > put a cache system on top of this libpq and you have the thing > you perhaps want to have. That's all you really need. Yes, but it's nice to compete on performance too. Whether libpq has inefficiencies that prevent that is to be seen. Many commercial ODBMSes are blindingly fast on object retrieval. > What indeed would be a big win, it the chance to retrieve different > result sets with one query ! I'm working on it.
В списке pgsql-hackers по дате отправления: