No I didn't. I'm using the "noob-approach", and using all default, no special optimization, because normally that's what the people around here do. :)
For ruby, python and java, I just got the drivers and used it in the simplest way.
The tests are all built on "synthetic" scenario, I cratead the base, tables, tests. So it's unlike to have some unexpected behavior happening, but I'll give a look anyway.
About caching plan / binary protocol (and I know very-little-almost-nothing about these), it can't be used with psycopg? Let's say that the jdbc driver use these techniques, shouldn't psycopg do the same? (let-me repeat that I may not know about what i'm talking here. :) )
2011/5/11 Daniele Varrazzo
<daniele.varrazzo@gmail.com>On Wed, May 11, 2011 at 1:36 PM, Israel Ben Guilherme Fonseca
<
israel.bgf@gmail.com> wrote:
> 1) I would say that it is a premature optimization, actually thats a Paper
> for my university, I'm doing some ORMxDirect Access comparisons between
> different languages and frameworks. After some tests, i got these "strange"
> results, that's why I called you guys. :)
> 2) That would be very nice if we could help to improve psycopg driver. If I
> did a smaller documented-test-suite and sent it to you would it be helpful?
Yes, any result that would improve the driver would be of course well accepted.
Before going for a well packaged test, have you seen what is the
difference in the communication? There may be some obvious (after you
know) design difference, such as the jdbc driver caching the plan, or
the results, or using the binary protocol.
Cheers,
-- Daniele