Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report |
Дата | |
Msg-id | 199806021621.MAA12356@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [INTERFACES] ODBC is slow with M$-Access Report ("Jose' Soares Da Silva" <sferac@bo.nettuno.it>) |
Ответы |
Re: [HACKERS] Re: [INTERFACES] ODBC is slow with M$-Access Report
|
Список | pgsql-hackers |
> > 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)
В списке pgsql-hackers по дате отправления: