Re: Parallel Seq Scan

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Seq Scan
Date: 2015-04-21 01:04:25
Message-ID: 5535A219.6050806@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-04-21 AM 03:29, Robert Haas wrote:
> On Wed, Apr 8, 2015 at 3:38 AM, Amit Langote wrote:
>> On 08-04-2015 PM 12:46, Amit Kapila wrote:
>>> Going forward, I think we can improve the same if we decide not to shutdown
>>> parallel workers till postmaster shutdown once they are started and
>>> then just allocate them during executor-start phase.
>>
>> I wonder if it makes sense to invent the notion of a global pool of workers
>> with configurable number of workers that are created at postmaster start and
>> destroyed at shutdown and requested for use when a query uses parallelizable
>> nodes.
>
> Short answer: Yes, but not for the first version of this feature.
>
> Longer answer: We can't actually very reasonably have a "global" pool
> of workers so long as we retain the restriction that a backend
> connected to one database cannot subsequently disconnect from it and
> connect to some other database instead. However, it's certainly a
> good idea to reuse the same workers for subsequent operations on the
> same database, especially if they are also by the same user. At the
> very minimum, it would be good to reuse the same workers for
> subsequent operations within the same query, instead of destroying the
> old ones and creating new ones. Notwithstanding the obvious value of
> all of these ideas, I don't think we should do any of them for the
> first version of this feature. This is too big a thing to get perfect
> on the first try.
>

Agreed.

Perhaps, Amit has worked (is working) on "reuse the same workers for
subsequent operations within the same query"

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-04-21 01:04:58 Re: Freeze avoidance of very large table.
Previous Message Peter Geoghegan 2015-04-21 00:23:16 Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0