Re: Mutli-threading and performance of ODBC
От | Dave Page |
---|---|
Тема | Re: Mutli-threading and performance of ODBC |
Дата | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B889F61F@mail.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Mutli-threading and performance of ODBC ("Stergios Zissakis" <szis@intranet.gr>) |
Ответы |
Re: Mutli-threading and performance of ODBC
Re: Mutli-threading and performance of ODBC |
Список | pgsql-odbc |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 09 March 2004 15:57 > To: Stergios Zissakis > Cc: pgsql-odbc@postgresql.org; Kostas Lykiardopoulos; > Dimitris Pantermalis > Subject: Re: [ODBC] Mutli-threading and performance of ODBC > > "Stergios Zissakis" <szis@intranet.gr> writes: > > 1. Studing the postgreSQL log, it is apparent that the the > ODBC driver > > switches off the Genetic Query Optimiser (geqo) and tries > to switch on > > another optimiser called (ksqo) which fails. What is the > ksqo optimiser? > > ksqo was a hack that disappeared several releases back. I do > not know why ODBC still has a reference to it (or why it > tried to force it on in the first place; IMHO a driver has no > business making that kind of decision). > > I would recommend removing both of those SETs from the driver code. I removed KSQO long ago for servers >= 7.3 - for < 7.3 it is a config option. GEQO is set via a config option - it is not forced on. > > 3. Also, using ODBC, in the log file of PostgreSQL, it is > seen that a > > lot of blank statements are generated. Can these blank statements > > affect the performance? > > The backend won't spend much time on a blank statement, but > if a separate network round trip is being incurred for each > one, that could get a tad expensive ... There is an empty connection sent during connection setup to check that the database is valid. I can't see any others in a commlog here though. Regards, Dave.
В списке pgsql-odbc по дате отправления: