Michael McCarthy wrote:
> Hello David:
>
> Thanks for the quick reply; it means a lot to me.
>
> I tried "SET ksqo TO 'on'", and it works fine for my problem query; it
> allowed 570 key sets to be resolved in 2 seconds, which is a big step
> forward.
>
> I am writing a layer which makes postgres one RDBMS (of several) which can
> support a generic object persistence framework. The use of "SET ksqo TO
> 'on'" is a postgres implementation detail which applications using the
> framework will not be aware of. I am faced with the problem of whether or
> not to use "SET ksqo TO 'on'" for all queries, or find some criteria for
> turning it on and off.
>
> A quick examination of backend/optimizer/prep/prepkeyset.c shows me that
> there is some qualification of a query for keyset optimization; is there
> any reason why I should not always set ksqo on?
The qualification is strict so that it can be left on without breaking other queries. Most MS ODBC users
use it all the time; I have yet to hear of it causing any problems.
>
>
>
> > There is a work around feature that works for queries that gererate a parse tree similar to yours.
> > ODBC tools generate these kinds of queries all the time. Keyset queries. To acivate the
> > feature: SET ksqo TO 'on'; It rewrites the parse tree into a series of UNIONs. Not optimal but
> > it works for rectangular where clauses. (n ANDs) x (m ORs)
> >
> > -- Here is an example using a 3 part key
> > select ... from foo where
> > (v1 = "?" AND v2 = "?" AND v3 ="?") OR -- line 1
> > (v1 = "?" AND v2 = "?" AND v3 ="?") OR -- line 2
> > ...
> > (v1 = "?" AND v2 = "?" AND v3 ="?") OR -- line 9
> > (v1 = "?" AND v2 = "?" AND v3 ="?"); -- line 10
> > -- The question marks are replaced with the constant key values
>
> ************