[Zope] best postgreSQL adapter?

[ender]

On Friday 09 March 2001 17:06, Federico Di Gregorio wrote:
>>> if you're going to be connect to postgres outside of zope i recommend not
>>> using PoPy. Its regularly crashes python for me when i try to do things
>>> any heavy db work from outside zope. heavy constituting using bind
>>> variables, stored procs, checking rowcount, description, etc. in
>>> accessing postgres external to zope i'd recommend using pygresql (the
>>> native non-standard interface not the dbi wrapper) or pgsql.
>>
>>while it still does not support direct call of stored procedures using
>>callproc(), psycopg is pretty stable on bind variables and also offers
>>a very nice type-casting system to convers postgres results to custom
>>python types.

incidentally, my attempts at 'heavy use' were for some tenative work i was 
doing on a postgres storage, but i ended up having too many problems getting 
any of the postgres adaptors to properly handle binary data (not in lob in a 
text field), bind variables, and calling of procs (converted over the 
OracleStorage to pl/pgsql procs) all at the same time. between the fact that 
a db -backed storage wasn't very useful in the first place and the difficulty 
in getting things working i shelved it.

i was wondering if there are any plans for psycopg to go beyond the db-api 
and support more of the functionality of libpq, such as asynch requests, and 
notifications. (yes, i know the line about contributions, but i'm more 
curious about your plans for psycopg).

>>> one thing to not about ZPygre is that it synchronizes all db access. if
>>
>>this is bad, because you can't rollback...

ok, i'll bite. why not?


>>> you're making lots of small queries this is not the adaptor for you. if
>>> you've got some large queries you're better off testing both and seeing
>>> which one gives you better throughput (probably PoPy, buts it not a sure
>>> thing).
>>
>>i am very interested in drivers performance: has anybody set up a test
>>of some kind to test this stuff? we use a simple test with 3 threads
>>doing simultaneous INSERTs and SELECTs, creating lots of cursors and
>>psycopg seems pretty fast but i would better like some *real* test.

hmmm... i vaguely recall someone posting some comparisions between pygre and 
popy in the last month or two, you'll have to check the searchable archives.

>>> >>any others?  psycopg mentions that it is designed for heavy multi
>>> >> threaded operations but popy seems more developed.
>>>
>>> psycopg has interesting arch, but if you're using postgres its good to
>>> keep in mind that libpq (the c client interface to postgres) does not
>>> support multiple threads sharing a connection. psycopg does internal
>>> bookeeping in
>>
>>that's why we came out with the "interesting arch" :) note that psycopg
>>does it better when you create lots of short-lived threads all using
>>the same connection and creating one or more cursor each.
>>
>>> the module itself after a connect to keep around a pool of connections.
>>> when it matures it should be a very good postgres adaptor for zope.
>>
>>ok, we wrote it in about 4 weeks, but let me say that psycopg is already
>>pretty stable. we know at least 1 company that switched its production site
>>from another driver (i won't say what) to psycopg because they had
>>stability problems... i am glad to say that the problems are now resolved
>>(mmm... or, maybe, psycopg simply destroyed their entire production server,
>>i can't say... :)
>>
>>jokes apart, a new product can't mature if nobody use it because it is
>>"still young", so try it out and send bug reports, thanx!

true, i'll try my attempts on a postgres storage on it and see what happens. 
although for something like a zodb storage the multiple connection thing is 
not useful since the zodb will synchronize access to the storage layer.

i'll see if i can convert my experiments into some unittests.

cheers

kapil