RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
От | Taral |
---|---|
Тема | RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) |
Дата | |
Msg-id | 000001bdedc6$6cf75d20$3b291f0a@taral обсуждение исходный текст |
Ответ на | Re: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-general |
> It currently convert to CNF so it can select the most restrictive > restriction and join, and use those first. However, the CNF conversion > is a memory exploder for some queries, and we certainly need to have > another method to split up those queries into UNIONS. I think we need > to code to identify those queries capable of being converted to UNIONS, > and do that before the query gets to the CNF section. That would be > great, and David Hartwig has implemented a limited capability of doing > this, but we really need a general routine to do this with 100% > reliability. Well, if you're talking about a routine to generate a heuristic for CNF vs. DNF, it is possible to precalculate the query sizes for CNF and DNF rewrites... For conversion to CNF: At every node: if nodeType = AND then f(node) = f(left) + f(right) if nodeType = OR then f(node) = f(left) * f(right) f(root) = a reasonably (but not wonderful) metric For DNF just switch AND and OR in the above. You may want to compute both metrics and compare... take the smaller one and use that path. How to deal with other operators depends on their implementation... Taral
В списке pgsql-general по дате отправления: