Re: Parallel plans and "union all" subquery

Поиск
Список
Период
Сортировка
От Luc Vlaming
Тема Re: Parallel plans and "union all" subquery
Дата
Msg-id ec24befa-4086-f547-d41f-c6d0699b9366@swarm64.com
обсуждение исходный текст
Ответ на Re: Parallel plans and "union all" subquery  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
On 27-11-2020 04:14, Greg Nancarrow wrote:
> On Thu, Nov 26, 2020 at 6:11 PM Luc Vlaming <luc@swarm64.com> wrote:
>>
>> If interesting I can make a draft of what this would look like if this
>> makes it easier to discuss?
>>
> 
> Sure, that would help clarify it.
Okay. I will try to build an example but this will take a few weeks as 
vacations and such are coming up too.

> 
> I did debug this a bit, but it seems my gut feeling was wrong, even
> though it knows a type coercion is required and can be done, the
> parse/analyze code doesn't actually modify the nodes in place "for
> fear of changing the semantics", so when the types don't exactly match
> it's all left up to the planner, but for this parse tree it fails to
> produce a parallel plan.
> 

Yes. However I think here also lies an opportunity, because to me it 
seems much more appealing to have the planner being able to deal 
correctly with all the situations rather than having things like 
flatten_simple_union_all() that provide a solution for the ideal case.

> Regards,
> Greg Nancarrow
> Fujitsu Australia
> 

Regards,
Luc
Swarm64



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module