RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
От | Taral |
---|---|
Тема | RE: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) |
Дата | |
Msg-id | 000001bdee4e$86688b20$3b291f0a@taral обсуждение исходный текст |
Ответы |
Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
|
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: