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?
Thanks for your help!
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
Michael McCarthy TCSI Corporation
michael@tcsi.com 1080 Marina Village Parkway
(510) 749-8739 Alameda, CA 94501
On Tue, 21 Dec 1999, David C Hartwig Jr wrote:
> 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