| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: [DESIGN] ParallelAppend |
| Date: | 2015-07-29 02:08:20 |
| Message-ID: | 55B83594.2000707@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-07-29 AM 11:02, Kouhei Kaigai wrote:
>>
>> ...
>> synchronous Append path vs. parallel asynchronous Append with Funnel
>> (below/above?) it. I guess the asynchronous version would always be
>> cheaper. So, even if we end up with non-parallel sub-plans do we still add
>> a Funnel to make Append asynchronous? Am I missing something?
>>
> I expect Funnel itself will get Append capability but run sub-plans in
> background workers, to simplify path constructions. So, if Funnel with
> multiple sub-plans have cheaper cost than Append, it will replace the
> AppendPath by FunnelPath.
>
> Regarding to the cost estimation, I don't think parallel version is always
> cheaper than traditional Append, because of the cost to launch background
> workers. It increases startup cost to process the relation, thus, if upper
> node prefers small startup cost (like Limit), traditional Append still has
> advantages.
>
Right, I almost forgot about the start-up cost.
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2015-07-29 02:26:29 | Typo in comment in ATPrepChangePersistence |
| Previous Message | Robert Haas | 2015-07-29 02:07:57 | Re: A little RLS oversight? |