Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.
Дата
Msg-id CAA4eK1LjR4Ej4SU6nx=S4EyibnUPfuksGhh0aHD-=u6A3YisPQ@mail.gmail.com
обсуждение исходный текст
Ответ на EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jul 7, 2016 at 1:23 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> Hi,
>
> I found $SUBJECT while trying to test parallel queries. Is this a bug?
>
>
> In not parallel mode, EXPLAIN ANALYZE reports the information about
> Sort Method as follows.
>
> =# EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;
>                                                             QUERY PLAN
>
-----------------------------------------------------------------------------------------------------------------------------------
>  Sort  (cost=180739.34..183239.34 rows=1000000 width=97) (actual
> time=1501.342..1836.057 rows=1000000 loops=1)
>    Sort Key: bid
>    Sort Method: external sort  Disk: 104600kB
>    ->  Seq Scan on pgbench_accounts  (cost=0.00..26394.00 rows=1000000
> width=97) (actual time=0.013..179.315 rows=1000000 loops=1)
>
>
> However, in parallel mode, it's not reported, as follows.
>
> =# SET force_parallel_mode TO on;
> =# EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;
>                                                                QUERY
> PLAN
>
-----------------------------------------------------------------------------------------------------------------------------------------
>  Gather  (cost=181739.34..284239.34 rows=1000000 width=97) (actual
> time=1507.138..2394.028 rows=1000000 loops=1)
>    Workers Planned: 1
>    Workers Launched: 1
>    Single Copy: true
>    ->  Sort  (cost=180739.34..183239.34 rows=1000000 width=97) (actual
> time=1503.112..1901.117 rows=1000000 loops=1)
>          Sort Key: bid
>          ->  Seq Scan on pgbench_accounts  (cost=0.00..26394.00
> rows=1000000 width=97) (actual time=0.021..181.079 rows=1000000
> loops=1)
>

I think this can never happen for force_parallel_mode TO off, because
we don't generate a gather on top of sort node.  The reason why we are
able to push Sort below gather, because it is marked as parallel_safe
(create_sort_path).  I think we should not mark it as parallel_safe.
Will investigate some more and send a patch.

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



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: pg_xlogfile_name_offset() et al and recovery
Следующее
От: Greg Stark
Дата:
Сообщение: Re: can we optimize STACK_DEPTH_SLOP