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: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of
> Merlin Moncure
> Sent: 27 juin 2005 10:29
> To: grupos
> Cc: pgsql-performance@postgresql.org
> 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
>
