PERFORMANCE ISSUE ODBC x LIBPQ C++ Application

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PERFORMANCE ISSUE ODBC x LIBPQ C++ Application

grupos
Hi !

My company is evaluating to compatibilizate our system (developed in
C++) to PostgreSQL.

Our programmer made a lot of tests and he informed me that the
performance using ODBC is very similar than using libpq, even with a big
number of simultaneous connections/queries. Of course that for us is
simpler use ODBC because will be easier to maintan as we already support
a lot of other databases using ODBC (MySQL, DB2, etc).

Someone already had this experience? What are the key benefits using
libpq insted of ODBC ?

Our application have a heavy load and around 150 concorrent users.

Regards,

Rodrigo Carvalhaes

--
Esta mensagem foi verificada pelo sistema de antiv?rus e
 acredita-se estar livre de perigo.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: PERFORMANCE ISSUE ODBC x LIBPQ C++ Application

Merlin Moncure
> Hi !
>
> My company is evaluating to compatibilizate our system (developed in
> C++) to PostgreSQL.
>
> Our programmer made a lot of tests and he informed me that the
> performance using ODBC is very similar than using libpq, even with a
big
> number of simultaneous connections/queries. Of course that for us is
> simpler use ODBC because will be easier to maintan as we already
support
> a lot of other databases using ODBC (MySQL, DB2, etc).
>
> Someone already had this experience? What are the key benefits using
> libpq insted of ODBC ?
>
> Our application have a heavy load and around 150 concorrent users.

The ODBC driver for postgresql implements its own protocol stack.
Unfortunately, it is still on protocol revision 2 (out of 3).  Also, IMO
libpq is a little better tested and durable than the odbc driver.  This
naturally follows from the fact that libpq is more widely used and more
actively developed than odbc.

If you are heavily C++ invested you can consider wrapping libpq yourself
if you want absolute maximum performance.  If you happen to be
developing on Borland platform give strong consideration to Zeos
connection library which is very well designed (it wraps libpq).

You might want to consider posting your question to the odbc list.

Merlin


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: PERFORMANCE ISSUE ODBC x LIBPQ C++ Application

Eric Lauzon
In reply to this post by grupos
i would take a peek at psqlodbc-8.0 drivers ..
i wouldn't battle with other version you might find such as (unixodbc
ones)


-elz


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Merlin Moncure
> Sent: 27 juin 2005 10:29
> To: grupos
> Cc: [hidden email]
> Subject: Re: [PERFORM] PERFORMANCE ISSUE ODBC x LIBPQ C++ Application
>
> > Hi !
> >
> > My company is evaluating to compatibilizate our system (developed in
> > C++) to PostgreSQL.
> >
> > Our programmer made a lot of tests and he informed me that the
> > performance using ODBC is very similar than using libpq, even with a
> big
> > number of simultaneous connections/queries. Of course that
> for us is
> > simpler use ODBC because will be easier to maintan as we already
> support
> > a lot of other databases using ODBC (MySQL, DB2, etc).
> >
> > Someone already had this experience? What are the key
> benefits using
> > libpq insted of ODBC ?
> >
> > Our application have a heavy load and around 150 concorrent users.
>
> The ODBC driver for postgresql implements its own protocol stack.
> Unfortunately, it is still on protocol revision 2 (out of 3).
>  Also, IMO libpq is a little better tested and durable than
> the odbc driver.  This naturally follows from the fact that
> libpq is more widely used and more actively developed than odbc.
>
> If you are heavily C++ invested you can consider wrapping
> libpq yourself if you want absolute maximum performance.  If
> you happen to be developing on Borland platform give strong
> consideration to Zeos connection library which is very well
> designed (it wraps libpq).
>
> You might want to consider posting your question to the odbc list.
>
> Merlin
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq