[Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > 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.
OK, but if we use UNION, how to we return the proper rows? Is there any
solution for that, and we are executing the query over and over again.
Any factoring would be faster than running those multiple queries,
wouldn't it?
Also, I amagine the case where we are doing a join, so we have:
SELECT *
FROM tab1, tab2
WHERE tab1.col1 = tab2.col2 AND
((a=1 and b=2 and c=3) OR
(a=1 and b=2 and c=4))
How do we do that with UNION, and return the right rows. Seems the
_join_ happending multiple times would be much worse than the factoring.
--
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
