Re: Getting sorted data from foreign server for merge join

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Getting sorted data from foreign server for merge join
Дата
Msg-id CAFjFpRdOO+nqMMnTBR-dYD1Or2WiVEdpkbPtH=8-EQzyfe1hkA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Getting sorted data from foreign server for merge join  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<div dir="ltr">Thanks.<br /></div><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Dec 23, 2015 at 12:24
AM,Robert Haas <span dir="ltr"><<a href="mailto:robertmhaas@gmail.com"
target="_blank">robertmhaas@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px#ccc solid;padding-left:1ex"><span class="">On Mon, Dec 21, 2015 at 6:34 AM, Ashutosh Bapat<br />
<<ahref="mailto:ashutosh.bapat@enterprisedb.com">ashutosh.bapat@enterprisedb.com</a>> wrote:<br /> >> I
wentover this patch in some detail today and did a lot of cosmetic<br /> >> cleanup.  The results are attached. 
I'mfairly happy with this<br /> >> version, but let me know what you think.  Of course, feedback from<br />
>>others is more than welcome also.<br /> >><br /> ><br /> > Attached patch with some cosmetic
changes(listed here for your quick<br /> > reference)<br /> > 1. , was replaced with ; in comment "inner join,
expressionsin the " at one<br /> > place, which is correct, but missed other place.<br /> > 2. The comment
"First,consider whether any each active EC is potentially"<br /> > should use either "any" or "each". I have
rewordedit as "First, consider<br /> > whether any of the active ECs is potentially ...". Or we can use "First,<br
/>> find all of the active ECs which are potentially ....".<br /> > 3. "having the remote side due the sort
generallywon't be any worse ..." -<br /> > instead of "due" we should use "do"?<br /> > 4. Added static prototype
offunction get_useful_ecs_for_relation().<br /> > 5. The comment "Extract unique EC for query, if any, so we don't
considerit<br /> > again." is too crisp. Phrase "Unique EC for query" is confusing; EC can not<br /> > be
associatedwith a query per say and EC's are always unique because of<br /> > canonicalisation. May be we should
rewordit as "Extract single EC for<br /> > ordering of query, if any, so we don't consider it again." Is that
cryptic<br/> > as well?<br /><br /></span>Thanks.  I committed this version with one small tweak.<br /><div
class="HOEnZb"><divclass="h5"><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a href="http://www.enterprisedb.com"
rel="noreferrer"target="_blank">http://www.enterprisedb.com</a><br /> The Enterprise PostgreSQL Company<br
/></div></div></blockquote></div><br/><br clear="all" /><br />-- <br /><div class="gmail_signature"><div dir="ltr">Best
Wishes,<br/>Ashutosh Bapat<br />EnterpriseDB Corporation<br />The Postgres Database Company<br /></div></div></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possible marginally-incompatible change to array subscripting
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Add scale(numeric)