Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: sferac(at)bo(dot)nettuno(dot)it (Jose' Soares Da Silva)
Cc: daveh(at)insightdist(dot)com, pgsql-interfaces(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org, vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev)
Subject: Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
Date: 1998-06-02 16:21:48
Message-ID: 199806021621.MAA12356@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
> 
> 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(at)candle(dot)pha(dot)pa(dot)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)

In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-06-02 16:34:40
Subject: Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
Previous:From: David HartwigDate: 1998-06-02 15:47:31
Subject: Re: [INTERFACES] ODBC is slow with M$-Access Report

pgsql-interfaces by date

Next:From: The Hermit HackerDate: 1998-06-02 16:34:40
Subject: Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
Previous:From: Byron NikolaidisDate: 1998-06-02 16:11:44
Subject: Where is Interfaces?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group