Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)

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.