Re: MIN/MAX optimization for partitioned table

On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark <gsstark(at)mit(dot)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