From: Bruce Momjian <maillist@candle.pha.pa.us>
To: sferac@bo.nettuno.it
Cc: daveh@insightdist.com
Cc: pgsql-interfaces@postgreSQL.org
Cc: pgsql-hackers@postgreSQL.org
Cc: vadim@sable.krasnoyarsk.su
Subject: Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
Date: Tue, 2 Jun 1998 12:21:48 -0400 (EDT)
Message-ID: <199806021621.MAA12356@candle.pha.pa.us> (raw)
In-Reply-To: <Pine.LNX.3.96.980601173507.10343A-100000@proxy.bazzanese.com>
>
> We are working on a project that IMHO give more prestige to
> PostgreSQL.
> The Hygea project concern the use of an Unix-like Operating sys-
> tem as "back-end" of a Client M$-windows application connected
> by ODBC that will be installed in about 80 Italian Helth Depart-
> ments for the veterinary controls and prevention.
> Therefore...
>
> O.S.: We choose Linux for his proved reliability.
>
> Client: We choose to develop the Client with M$-Access because we
> need (unfortunately) a complete integration with Micro$oft World.
>
> Database: We choose PostgreSQL for his reliability and for his
> compatibility with SQL/92 standard recommendation and for his ex-
> cellent technical support provided by "The PostgreSQL Development
> Team" and his mailing lists.
Great.
>
> Nevertheless the union among M$-Access and PostgreSQL is quite
> suffered for the following reasons:
>
> 1. The PostgreSQL doesn't use the index with "OR" operator and
> so is not possible to define a multiple key to use with M$-Access
> and we need to retreat using OID as primary keys (thanks to Byron
> Nikolaidis and David Hartwig of insightdist.com that are doing a
> really great job with ODBC driver), but with the obvious consequences.
Yes, we need to work on this. I am sure performance really suffers
because of this. Vadim, is this on your short list?
>
> 2. As PostgreSQL doesn't allow an "ORDER BY" on columns not
> included in the target list of the "SELECT", (I know that it is
> SQL/92 standard, but IMO it's a fool thing), therefore, is not possible
> to have the "dynaset "sorted for any field that is different from
> the key (in our case the useless OIDs).
David at Insight just added this, so it certainly will be in 6.4.
>
> 3. The times required to run complex reports (for example those that
> include LEFT JOINS) is very long (about 15 minutes to retrieve
> 2850 rows).
Yea, we need this too. Not sure where we are with this. Can you give
an example?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: maillist@candle.pha.pa.us, sferac@bo.nettuno.it, daveh@insightdist.com, pgsql-hackers@postgreSQL.org, vadim@sable.krasnoyarsk.su
Subject: Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
In-Reply-To: <199806021621.MAA12356@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox