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  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Enhancement - code completion when typing set search_path
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: make check failure for 8.4.0