Thread: Win ODBC drivers for Postgres

Win ODBC drivers for Postgres

From
Mihai Gheorghiu
Date:
The following is a quote from a consultant's opinion on my intention to
migrate to Postgresql.
Quote:
[ODBC public domain drivers] are immature, inefficient and are network
bandwidth hogs. The public domain drivers don't support connection caching
which reuses an existing database connection for same queries to reduce the
query result time.
Unquote.
Please comment.

Best regards,

Mihai

PS See also pgsql-general for opinion on Postgres :-)



Re: Win ODBC drivers for Postgres

From
"Byron Nikolaidis"
Date:
Hey there partner,

To quote the immortal Butthead:  "uhhhh....................., ok."

Seriously, I wonder how this "consultant" came up with this?   Sounds
awefully generalized.   I think I could say that line about anything,
including ODBC itself.

Also, many of the compromises of the ODBC driver are based on shortcomings
of the backend.  Jeez, we still "simulate" a Prepared Statement because
there isn't one in the backend.   Is the backend ever gonna have this?AFAIK,
the JDBC driver simulates the prepared statement also.

Some may remember the "declare/fetch" feature of the ODBC driver, that makes
use of postgres cursors.  This feature was added to help with the network
bandwidth problem -- instead of getting the entire query result, it fetched
it in chunks when required.

Yeah, so maybe connection pooling would be nice, but most things use one or
two connections don't they?   Do most processes keep asking odbc for a new
connection?

Byron

----- Original Message -----
From: Mihai Gheorghiu <tanhq@bigplanet.com>
To: <pgsql-interfaces@postgresql.org>
Sent: Wednesday, June 07, 2000 10:36 AM
Subject: [INTERFACES] Win ODBC drivers for Postgres


> The following is a quote from a consultant's opinion on my intention to
> migrate to Postgresql.
> Quote:
> [ODBC public domain drivers] are immature, inefficient and are network
> bandwidth hogs. The public domain drivers don't support connection caching
> which reuses an existing database connection for same queries to reduce
the
> query result time.
> Unquote.
> Please comment.
>
> Best regards,
>
> Mihai
>
> PS See also pgsql-general for opinion on Postgres :-)
>



Re: Win ODBC drivers for Postgres

From
"Sam O'Connor"
Date:
Having just ported my Postgres ODBC application to work with DB2,
MSSQL, Oracle and  Informix I'm quite interested in the differences
between ODBC drivers. I've implemented a simple connection pooling
scheme on top of ODBC but it means that I'm not making use of the
more clever schemes built into the commercial drivers. The main
area where I would like to hand responsibility to the driver is
thread safety. I'd like to be able to open a connection in a thread
and have it behave like a private connection even if the driver
multiplexes it though an existing connection. In my current system
I have to handle putting mutexs around all the database access code
which is annoying. Thread safe connection pooling would be very
useful in PgODBC.

Does anyone have any experience or knowledge about how the Pg ODBC
drivers behave in a multithreaded application?

Another thing I've noticed is that the transaction handling is
somewhat broken in the PG ODBC driver.
I make a connection with auto commit turned off.
I make a statement with the connection.
I do a series of large object operations. (bind, insert, send data) (Which must be in a single transaction to work.)
It doesn't work.

But if I execute some other query with the statement before
doing the lo stuff, or if I do an explicit BEGIN it works fine.
All my lo access code is now preceded by:
if (db_type == Db_type_PostgreSQL)execute direct ("BEGIN") 

Sam O'Connor

Byron Nikolaidis wrote:
> 
> Hey there partner,
> 
> To quote the immortal Butthead:  "uhhhh....................., ok."
> 
> Seriously, I wonder how this "consultant" came up with this?   Sounds
> awefully generalized.   I think I could say that line about anything,
> including ODBC itself.
> 
> Also, many of the compromises of the ODBC driver are based on shortcomings
> of the backend.  Jeez, we still "simulate" a Prepared Statement because
> there isn't one in the backend.   Is the backend ever gonna have this?AFAIK,
> the JDBC driver simulates the prepared statement also.
> 
> Some may remember the "declare/fetch" feature of the ODBC driver, that makes
> use of postgres cursors.  This feature was added to help with the network
> bandwidth problem -- instead of getting the entire query result, it fetched
> it in chunks when required.
> 
> Yeah, so maybe connection pooling would be nice, but most things use one or
> two connections don't they?   Do most processes keep asking odbc for a new
> connection?
> 
> Byron
> 
> ----- Original Message -----
> From: Mihai Gheorghiu <tanhq@bigplanet.com>
> To: <pgsql-interfaces@postgresql.org>
> Sent: Wednesday, June 07, 2000 10:36 AM
> Subject: [INTERFACES] Win ODBC drivers for Postgres
> 
> > The following is a quote from a consultant's opinion on my intention to
> > migrate to Postgresql.
> > Quote:
> > [ODBC public domain drivers] are immature, inefficient and are network
> > bandwidth hogs. The public domain drivers don't support connection caching
> > which reuses an existing database connection for same queries to reduce
> the
> > query result time.
> > Unquote.
> > Please comment.
> >
> > Best regards,
> >
> > Mihai
> >
> > PS See also pgsql-general for opinion on Postgres :-)
> >


RE: Win ODBC drivers for Postgres

From
Peter Mount
Date:
See below...

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council

> -----Original Message-----
> From:    Byron Nikolaidis [SMTP:byron.nikolaidis@home.com]
> Sent:    Wednesday, June 07, 2000 10:31 PM
> To:    Mihai Gheorghiu; pgsql-interfaces@postgresql.org
> Subject:    Re: [INTERFACES] Win ODBC drivers for Postgres
> 
> Hey there partner,
> 
> To quote the immortal Butthead:  "uhhhh....................., ok."
> 
> Seriously, I wonder how this "consultant" came up with this?   Sounds
> awefully generalized.   I think I could say that line about anything,
> including ODBC itself.[Peter Mount]  I can think of a few non-public domain items that are
even worse...

> Also, many of the compromises of the ODBC driver are based on shortcomings
> of the backend.  Jeez, we still "simulate" a Prepared Statement because
> there isn't one in the backend.   Is the backend ever gonna have
> this?AFAIK,
> the JDBC driver simulates the prepared statement also.
> [Peter Mount]  Yes, JDBC does simulate prepared statements, but as
soon as the backend supports it (which, some one correct me, may be possible
after a parser rewrite?) it will be changed over. This is one of the big
performance hits in JDBC at the moment.

> Some may remember the "declare/fetch" feature of the ODBC driver, that
> makes
> use of postgres cursors.  This feature was added to help with the network
> bandwidth problem -- instead of getting the entire query result, it
> fetched
> it in chunks when required.
> [Peter Mount]  I want to add this capability to JDBC, especially the
JDBC2 driver, as it's ResultSet can implicitly handle cursors. I was
originally going to do it for 7.0.

> Yeah, so maybe connection pooling would be nice, but most things use one
> or
> two connections don't they?   Do most processes keep asking odbc for a new
> connection?[Peter Mount]  I'm not sure about ODBC, but in JDBC a lot of people
use connection pools, especially with Servlets or CORBA applications.

> Byron
> 
> ----- Original Message -----
> From: Mihai Gheorghiu <tanhq@bigplanet.com>
> To: <pgsql-interfaces@postgresql.org>
> Sent: Wednesday, June 07, 2000 10:36 AM
> Subject: [INTERFACES] Win ODBC drivers for Postgres
> 
> 
> > The following is a quote from a consultant's opinion on my intention to
> > migrate to Postgresql.
> > Quote:
> > [ODBC public domain drivers] are immature, inefficient and are network
> > bandwidth hogs. The public domain drivers don't support connection
> caching
> > which reuses an existing database connection for same queries to reduce
> the
> > query result time.
> > Unquote.
> > Please comment.
> >
> > Best regards,
> >
> > Mihai
> >
> > PS See also pgsql-general for opinion on Postgres :-)
> >


RE: Win ODBC drivers for Postgres

From
Nicolas Huillard
Date:
Yes, this seems very generalized... and sounds like a marketing speech. 
What is the background of this consultant ? Many times, this is only a 
matter of who pays him and what he really knows.

Nicolas Huillard

-----Message d'origine-----
De:    Byron Nikolaidis [SMTP:byron.nikolaidis@home.com]
Date:    mercredi 7 juin 2000 23:31
A:    Mihai Gheorghiu; pgsql-interfaces@postgresql.org
Objet:    Re: Win ODBC drivers for Postgres

Hey there partner,

To quote the immortal Butthead:  "uhhhh....................., ok."

Seriously, I wonder how this "consultant" came up with this?   Sounds
awefully generalized.   I think I could say that line about anything,
including ODBC itself.

Also, many of the compromises of the ODBC driver are based on shortcomings
of the backend.  Jeez, we still "simulate" a Prepared Statement because
there isn't one in the backend.   Is the backend ever gonna have 
this?AFAIK,
the JDBC driver simulates the prepared statement also.

Some may remember the "declare/fetch" feature of the ODBC driver, that 
makes
use of postgres cursors.  This feature was added to help with the network
bandwidth problem -- instead of getting the entire query result, it fetched
it in chunks when required.

Yeah, so maybe connection pooling would be nice, but most things use one or
two connections don't they?   Do most processes keep asking odbc for a new
connection?

Byron

----- Original Message -----
From: Mihai Gheorghiu <tanhq@bigplanet.com>
To: <pgsql-interfaces@postgresql.org>
Sent: Wednesday, June 07, 2000 10:36 AM
Subject: [INTERFACES] Win ODBC drivers for Postgres


> The following is a quote from a consultant's opinion on my intention to
> migrate to Postgresql.
> Quote:
> [ODBC public domain drivers] are immature, inefficient and are network
> bandwidth hogs. The public domain drivers don't support connection 
caching
> which reuses an existing database connection for same queries to reduce
the
> query result time.
> Unquote.
> Please comment.
>
> Best regards,
>
> Mihai
>
> PS See also pgsql-general for opinion on Postgres :-)
>




Re: Win ODBC drivers for Postgres

From
Mihai Gheorghiu
Date:
Ladies and gentlemen,
Please accept my sincere apologies.
I was just as frustrated as you were when reading that person's Memo. He
tried to take advantage of what the French say, "Les absents ont toujours
tort." - Absents are always wrong.
Given my very limited experience with PostgreSQL, I needed arguments to
support my option.
Now the jury is out. I hope they will vote for Open Source, at least for
financial reasons.
Actually the document tried to justify a network architecture that required
transactional replication (2way :-(  MS claims it is built in their SQL7.
If this will be a requirement, what is the timeframe for having that
implemented in PostgreSQL? It is my understanding this can be done now too,
only by programming.

Best regards,

Mihai



>Hello,
>
>At 10.36 07/06/00 -0400, you wrote:
>>Quote:
>>[ODBC public domain drivers] are immature, inefficient and are network
>>bandwidth hogs. The public domain drivers don't support connection caching
>>which reuses an existing database connection for same queries to reduce
the
>>query result time.
>
>well, don't know about the internals of the PostODBC driver, anyway I have
>performed many tests on it. The latest version of the driver coupled with
>the latest version of PostgreSQL with my tests was about 2 times faster
>than MS SQL Server 6.5 with its own ODBC Driver, especially when more than
>one concurrent connection was used. And in my experience (real experience,
>not benchmarks) most commercial databases are slower than MS SQL Server and
>have ODBC drivers that are almost useless because of bugs, unimplemented
>features and many other quirks. I''m just working with Centura SQL Base
>(version 6.1.something) with its own ODBC. It's just a pain. It doesn't
>report indices and primary keys so Visual Basic with DAO refuse to perform
>any write operation with it. I have to build complex SQL statements to do
>any change to the data contained in the database. Every now and then it
>refuses to connect to the database with no apparent reason, and so on.
>         I simply completely disagree with the above statement. There's
>nothing slower than something that simply doesn't work at all, and many
>commercial databases simply doesn't work, who cares if they are faster when
>they work?
>
>Bye!
>--
> Denis Sbragion
> InfoTecna
> Tel, Fax: +39 039 2324054
> URL: http://www.infotecna.it
>