Bruce Momjian wrote:
> I have another idea.
>
> When we cnfify, this:
>
> (A AND B) OR (C AND D)
>
> becomes
>
> (A OR C) AND (A OR D) AND (B OR C) AND (B OR D)
>
> however if A and C are identical, this could become:
>
> (A OR A) AND (A OR D) AND (B OR A) AND (B OR D)
>
> and A OR A is A:
>
> A AND (A OR D) AND (B OR A) AND (B OR D)
>
> and since we are now saying A has to be true, we can remove OR's with A:
>
> A AND (B OR D)
>
> Much smaller, and a big win for queries like:
>
> SELECT *
> FROM tab
> WHERE (a=1 AND b=2) OR
> (a=1 AND b=3)
>
> This becomes:
>
> (a=1) AND (b=2 OR b=3)
>
> which is accurate, and uses our OR indexing.
>
> Seems I could code cnfify() to look for identical qualifications in two
> joined OR clauses and remove the duplicates.
>
> Sound like big win, and fairly easy and inexpensive in processing time.
>
> Comments?
Apologies for not commenting sooner. I have been incognito.
As to your earlier question, Bruce, the KSQO patch rewrites qualifying
queries as UNIONs.
(A AND B) OR (C AND D) ==> (A AND B) UNION (C AND D)
The rules to qualify are fairly strict. Must be have ANDs; rectangular in
shape; all (VAR op CONST) type nodes; minimum of 10 nodes; etc. I was
targeting the keysets queries generated by ODBC tools.
As for the current direction this thread is going, (factoring) I have one
word of caution. PREPARE. If you take this route, you will never be able
to implement a workable PREPARE statement. I believe that in order for
PostgrerSQL ever become a industrial strength client/server it must implement
a PREPARE statement with parameters.