Обсуждение: 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 :-)
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 :-) >
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 :-)
> >
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 :-) > >
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 :-) >
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 >