db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Carter" <joe.car...@excite.com>
Subject Re: Performance issues when using postgresql-8.1-404.jdbc3.jar
Date Wed, 14 Jun 2006 13:45:06 GMT
On 14/06/06, Tassos Bassoukos <abassouk@gmail.com> wrote:
> On 6/14/06, Joe Carter <joe.carter@excite.com> wrote:
> > Hi,
> >
> > Thanks for the info.
> > I've tried it and it makes no obvious difference to the speed.
> >
> > FWIW my timings for selects (for my particular test)
> > Standard Torque: ~10 seconds
> > Raw SQL: ~4 seconds
> > SQL as Prepared Statement: ~ 3 seconds.
> >
> > Curiously inserts have no discernable difference.
> Interesting. Note that my fix probably applies only to postgres, due
> to specific driver architecture. A way to log all SQL statements that
> are emitted by the JVM (and their duration) would help.

Agreed - p6spy returns the normal statements but I believe it doesn't
handle metadata - which is the prime suspect here.

Note that torque has overhead when lots and lots of rows are returned
> (memory- and cpu-wise), so that may affect your timings.

Yes, I was aware of that. My tests return single rows. Our application
generally does that so it's representative for me.

And yes, in my case inserts/updates have no timing difference either.
> Tassos Bassoukos

For now I'm manually coding my hotspot queries but hopefully a pattern will
fall out which would be suitable for generation. Getting rid of the need
for the metadata would be nice. I think torque has all of the information it
not to require access to the metadata, so I'm sure this is possible.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message