Re: Mutli-threading and performance of ODBC

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 09 March 2004 15:57
> To: Stergios Zissakis
> Cc: pgsql-odbc(at)postgresql(dot)org; Kostas Lykiardopoulos;
> Dimitris Pantermalis
> Subject: Re: [ODBC] Mutli-threading and performance of ODBC
>
> "Stergios Zissakis" <szis(at)intranet(dot)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.