On 13 November 2015 at 13:38, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, Nov 11, 2015 at 11:40 PM, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
>> yes - the another little bit unclean in EXPLAIN is number of workers. If I
>> understand to the behave, the query is processed by two processes if workers
>> in the explain is one.
> You are right and I think that is current working model of Gather
> node which seems okay. I think the more serious thing here
> is that there is possibility that Explain Analyze can show the
> number of workers as more than actual workers working for Gather
> node.  We have already discussed that Explain Analyze should
> the actual number of workers used in query execution, patch for
> the same is still pending.

This may have already been discussed before, but in a verbose output,
would it be possible to see the nodes for each worker?


# explain (analyse, buffers, timing, verbose, costs) select count(*)
from js where content->'tags'->>'title' like '%de%';
 Aggregate  (cost=105557.59..105557.60 rows=1 width=0) (actual
time=400.752..400.752 rows=1 loops=1)
   Output: count(*)
   Buffers: shared hit=175333
   ->  Gather  (cost=1000.00..104931.04 rows=250621 width=0) (actual
time=400.748..400.748 rows=0 loops=1)
         Output: content
         Number of Workers: 2
         Buffers: shared hit=175333
         ->  Parallel Seq Scan on public.js  (cost=0.00..39434.47
rows=125310 width=0) (actual time=182.256..398.14 rows=0 loops=1)
               Output: content
               Filter: (((js.content -> 'tags'::text) ->>
'title'::text) ~~ '%de%'::text)
               Rows Removed by Filter: 626486
               Buffers: shared hit=87666
         ->  Parallel Seq Scan on public.js  (cost=0.00..39434.47
rows=1253101 width=0) (actual time=214.11..325.31 rows=0 loops=1)
               Output: content
               Filter: (((js.content -> 'tags'::text) ->>
'title'::text) ~~ '%de%'::text)
               Rows Removed by Filter: 6264867
               Buffers: shared hit=876667
 Planning time: 0.085 ms
 Execution time: 414.713 ms
(14 rows)

And perhaps associated PIDs?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to