RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
Taral <taral@mail.utexas.edu>
From: "Taral" <taral@mail.utexas.edu>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: <jwieck@debis.com>, <hackers@postgreSQL.org>
Date: 1998-10-02T21:49:26Z
Lists: pgsql-hackers, pgsql-general
> > Very nice, but that's like trying to code factorization of > numbers... not > > pretty, and very CPU intensive on complex queries... > > Yes, but how large are the WHERE clauses going to be? Considering the > cost of cnfify() and UNION, it seems like a clear win. Is it general > enough to solve our problems? Could be... the examples I received where the cnfify() was really bad were cases where the query was submitted alredy in DNF... and where the UNION was a simple one. However, I don't know of any algorithms for generic simplification of logical constraints. One problem is resolution/selection of factors: SELECT * FROM a WHERE (a = 1 AND b = 2 AND c = 3) OR (a = 4 AND b = 2 AND c = 3) OR (a = 1 AND b = 5 AND c = 3) OR (a = 1 AND b = 2 AND c = 6); Try that on for size. You can understand why that code gets ugly, fast. Somebody could try coding it, but it's not a clear win to me. My original heuristic was missing one thing: "Where the heuristic fails to process or decide, default to CNF." Since that's the current behavior, we're less likely to break things. Taral