Re: ODBC Driver performance comparison - Mailing list pgsql-odbc

From Vladimir Romanov
Subject Re: ODBC Driver performance comparison
Date
Msg-id CAJ4CROhDHAGLkX5xKi_9s41jO1nrHBOHCqh=-Qvz6u=cXW4J=Q@mail.gmail.com
Whole thread Raw
In response to Re: ODBC Driver performance comparison  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-odbc
There 3 runs of commercial application with constant load on same PC,
13:58-14:17 - mysql,
14:35-14:55 - PostgreSql,
15:03-15:20 - Timesten
You can see high softirq usage on Posgresql. This is network driver related.

Here you can found information how performance report collected http://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html.


On Fri, Sep 5, 2014 at 10:40 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 09/05/2014 08:53 AM, Vladimir Romanov wrote:
Hello all!
I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare
performance on very simple request. Database always located on same PC as
test application. Test PC - Lenovo T500, Cnetos 6.5 64, 8 Gb RAM, SSD.
I found what PostgreSql ODBC driver is slowest in comparison.
IMHO problems related to protocol used. I can't use SHM connection to
server or even UNIX socket.

Actually, you can use a UNIX domain socket with psqlodbc. Just put the path to the socket, e.g. "/tmp", in the Servername property, instead of the hostname. That's assuming psqlodbc was compiled with libpq support, (--with-libpq configure option), but I'm pretty sure that's the default on all major distributions.

perftool report - http://freepcrf.com/files/db_test_pq.pdf

Would be interesting to get the psqlodbc function names in the chart. Any chance you could re-run the benchmark with a debug-enabled build?

It's interesting that 10.7% of the runtime seems to be spent in __tz_convert() function, called indirectly by SQLExecute. Off the top of my head, I don't see where that call is coming from. I wouldn't expect SQLExecute to do much with timezones, at least when there are no timestamp fields involved.

It might also be fairly straightforward to optimize the sprintf/sscanf function calls. They're probably used to convert between integers and strings, and it should be possible write some sort of fast-paths for those conversions.

Are you measuring wall-clock time or CPU time? If it's CPU time, I'm surprised that the I/O-related syscalls, poll(), send() and recv(), are so high on the profile. If not, there isn't much you can do in the client side to make them faster, as the time is simply spent waiting for the server.

- Heikki



--
Vladimir Romanov

pgsql-odbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: ODBC Driver performance comparison
Next
From: Heikki Linnakangas
Date:
Subject: Buffer overflows in SQLGetData corner cases