On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark <gsst...@mit.edu> wrote: > Neat! I haven't read the patch yet but I have some questions. > > Does this handle the case where some partitions have an index and > others don't? Ie. Does it just apply the regular optimization to each > partition and then slap on the aggregate node? I think that's actually > a realistic case because people often don't have indexes on empty > partitions like the parent partition or a new partition which has just > been added and doesn't have indexes yet. > > Is there any overlap with the ordered-append patch which is also in > the pipeline? afaict it covers similar cases but doesn't actually > overlap since the min/max optimization avoids having to do a sort > anywhere. > > -- > greg > http://mit.edu/~gsstark/resume.pdf <http://mit.edu/%7Egsstark/resume.pdf> > > > Hi Greg,
My colleague, Jeff Davis, just pointed me to the work that you're doing with MergeAppend. I didn't know about it. Yes, it does handle the case where no index exists in the child partition. It defaults to the Seqscan plan for that particular partition because it still depends on the aggregate node on top of the append node. I haven't looked at your MergeAppend patch so I don't know how much overlap there is. Based on my limited understanding of it, I think it may be two different approaches to optimizing the same problem with yours being a more general solution that solves a wider set of optimizations for partitioned tables while I'm trying to solve a very specific problem. You are also correct that my patch will not have to sort on partitions without the appropriate index, so the plan it generates should be cheaper. Any more thoughts about my patch or ways of making the two patches work together would be greatly appreciated. Thanks, Alan
