Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
Date
Msg-id 199810040157.VAA04640@candle.pha.pa.us
Whole thread Raw
In response to RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)  ("Taral" <taral@mail.utexas.edu>)
Responses RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)  ("Taral" <taral@mail.utexas.edu>)
List pgsql-hackers
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?

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Dumping of views -- done!
Next
From: "Taral"
Date:
Subject: RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)