On Mon, 15 Jul 2002, Josh Berkus wrote: > Stephan, > > > We had a discussion recently on -general about this. Right now the > > planner won't push the conditions down into the arms of the union because > > noone's been sure under what conditions the optimization is safe. > > So, if performance is horrible with the view, I should use a dummy table to > hold the Unioned data and index that instead?
Possibly. > I can understand the difficultyof optimization. However, the example I > supplied is the simplest of unions, and the two Seq Scans do seem to be > proceeding against each table seperately. I think for very simple Unions > (i.e. no grouping, no filtering within subqueries, etc.) that index usage > would be reasonable to implement. I don't think it's a difficulty of implementation thing. I'd guess that alot of the current stuff for shoving down conditions would apply (I haven't looked, though). It's more a case of making sure the optimization cannot be a false one that changes the results. What we need is someone to sit down and analyze the cases in a serious way. I think that for union all, conditions other than non-stable ones can be pushed down. For union, I think there might be issues due to the removal of duplicates in certain cases where the results will change, but that the results may not be deterministic in such cases anyway (like a case where two values are not exactly the same but aren't distinct due to collation or some such and so the system picks an arbitrary one and that arbitrary one affects the output of query). I have no good idea for EXCEPT and INTERSECT. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
