Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia
Дата
Msg-id 16315.1466538226@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 21, 2016 at 1:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Also, I got rid of the target_parallel argument to
>> apply_projection_to_path, as I thought that that was just way too much
>> interconnection between apply_projection_to_path and its callers than
>> is justified for what it saves (namely one call of has_parallel_hazard
>> when planning a Gather).  In general, having that argument could *add*
>> extra calls of has_parallel_hazard, since callers might have to do
>> that computation whether or not a Gather is present.

> I had a feeling you weren't going to like that, but it also didn't
> seem great to redo that computation for every path.  Right now, we
> only need it for Gather paths, but if we start marking subquery RTEs
> as parallel-safe and fix upper rels to correctly set
> consider_parallel, I have a feeling this is going to be needed more.
> But feel free to ignore that for now since I don't have a completely
> well-thought-out theory on this.

If that does start being a problem, I'd be inclined to address it by
teaching PathTarget to track whether its contents are parallel-safe.
For now, though, I think we don't need the complication.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Reviewing freeze map code
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Reviewing freeze map code