Re: MIN/MAX optimization for partitioned table
От | Alan Li |
---|---|
Тема | Re: MIN/MAX optimization for partitioned table |
Дата | |
Msg-id | 782056770907171505h428ee9el33dec178b5c792ac@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MIN/MAX optimization for partitioned table (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: MIN/MAX optimization for partitioned table
|
Список | pgsql-hackers |
<div class="gmail_quote">On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark <span dir="ltr"><<a href="mailto:gsstark@mit.edu">gsstark@mit.edu</a>></span>wrote:<br /><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Neat! I haven't read thepatch yet but I have some questions.<br /><br /> Does this handle the case where some partitions have an index and<br/> others don't? Ie. Does it just apply the regular optimization to each<br /> partition and then slap on the aggregatenode? I think that's actually<br /> a realistic case because people often don't have indexes on empty<br /> partitionslike the parent partition or a new partition which has just<br /> been added and doesn't have indexes yet.<br /><br/> Is there any overlap with the ordered-append patch which is also in<br /> the pipeline? afaict it covers similarcases but doesn't actually<br /> overlap since the min/max optimization avoids having to do a sort<br /> anywhere.<br/><font color="#888888"><br /> --<br /> greg<br /><a href="http://mit.edu/%7Egsstark/resume.pdf" target="_blank">http://mit.edu/~gsstark/resume.pdf</a><br/><br /><br /></font></blockquote></div>Hi Greg,<br /><br /> Mycolleague, Jeff Davis, just pointed me to the work that you're doing with MergeAppend. I didn't know about it.<br /><br/>Yes, it does handle the case where no index exists in the child partition. It defaults to the Seqscan plan for thatparticular partition because it still depends on the aggregate node on top of the append node.<br /><br /> I haven'tlooked at your MergeAppend patch so I don't know how much overlap there is. Based on my limited understanding ofit, I think it may be two different approaches to optimizing the same problem with yours being a more general solutionthat 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 planit generates should be cheaper.<br /><br />Any more thoughts about my patch or ways of making the two patches work togetherwould be greatly appreciated.<br /><br />Thanks, Alan<br />
В списке pgsql-hackers по дате отправления: