Re: Alternative new libpq interface.
От | Chris Bitmead |
---|---|
Тема | Re: Alternative new libpq interface. |
Дата | |
Msg-id | 396A72C0.7B963179@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: > > On Thu, 06 Jul 2000 15:50:13 +1000, Chris Bitmead wrote: > > > > >My idea is that there should be a very low level interface that has a > >minimum of bloat and features and caching and copying. This would be > >especially nice for me writing an ODMG interface because the ODMG > >interface would be needing to cache and copy things about so having > >libpq doing it too is extra overhead. It could also form the basis of > >a trivial re-implementation of the current libpq in terms of this > >interface. > > What does it mean: ODMG interface. I've the ODMG 3.0 book in front > of me and i do not know, what you would like to create ... why is > caching and copying a need for ODMG ??? Each programming language has a specified ODMG interface. Database objects are mapped 1:1 with language objects. Every time you read a database object a language object is created to represent it. Now if you read the same database object in different places in your code. Maybe the same object is "navigated" to via different paths, you don't want two objects created in memory to represent that object. If that happened you could have a confusing integrity situation. So with an ODMG interface it keeps track of what database objects are in memory at any one time - think of it as a cache, and makes sure that if you request the same object again, it doesn't construct a new one but returns the existing one. Of course when you create one of these language objects, the values must be copied into the fields of the object. That's where the copying comes in. Now some object databases are implemented by just transferring whole database pages to the client side. Obviously they have pretty low overhead in terms of memory copying data from one place to another. A postgres style architecture _can_ compete with this, but I suspect it must try harder in libpq in terms of how many times a bit of memory coming in is copied around the place. (Or maybe not. Maybe that is premature optimisation).
В списке pgsql-hackers по дате отправления: