Re: Parallel Seq Scan

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Seq Scan
Date: 2015-11-14 03:12:49
Message-ID: CAA4eK1+7ZCKxcUh24GZ7fSWR6r=Fbfit2SXxYkX3xiR7q0nvwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 13, 2015 at 9:16 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>
> On 13 November 2015 at 15:22, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > There will be hardly any difference in nodes for each worker and it
could
> > be very long plan for large number of workers. What kind of additional
> > information you want which can't be shown in current format.
>
> For explain plans, not that useful, but it's useful to see how long
> each worker took for explain analyse.
>

The statistics related to buffers, timing and infact rows filtered will be
different for each worker, so it sounds sensible to me to display separate
plan info for each worker or at least display the same in verbose or some
other mode and then display aggregated information at Gather node. The
only point that needs more thought is that parallel plans will look big for
many number of workers. I think this will need somewhat substantial
changes than what is done currently for parallel seq scan, so it is better
if others also share their opinion about this form of display of information
for parallel queries.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-11-14 07:50:20 Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Previous Message Tom Lane 2015-11-14 00:42:49 Re: Inaccurate results from numeric ln(), log(), exp() and pow()