Re: Alternative new libpq interface.

Поиск
Список
Период
Сортировка
От M.Feldtmann@t-online.de (Marten Feldtmann)
Тема Re: Alternative new libpq interface.
Дата
Msg-id 13CEel-25KlBgC@fwd04.sul.t-online.com
обсуждение исходный текст
Ответ на Re: Alternative new libpq interface.  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
Список pgsql-hackers
On Tue, 11 Jul 2000 15:50:10 +1000, Chris Bitmead wrote:

>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.

Ok, then the new libpg has no own cache. That was not clear in your
posting. Databases like Versant and Oracle do have client based
caching system, which are NOT the language dependant cache - but
an overall client based cache. This is mainly due to performance
improvements they expect from that feature.

> 
>>  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.
Which is handled by the language binding ... correct ?
I had a strange feeling when you wrote, that you want to write
an ODMG interface, but never ever mentioned a programming language ! 
Therefore I thought you would like to create a new libpg with 
some support for an ODMG interface and I asked myself: what is
so important, that I need to write a new lipq


>
>>  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.
> 
Hmmm, what should I say. I've seen PostgreSQL beeing blindingly
fast fetching objects belonging to associations from one
object. This has mostly something to do with the object model
and it's mapping into the database ...
Marten
----

Marten Feldtmann, Germany



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: Performance problem in aset.c
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: Vacuum only with 20% old tuples