On 13 November 2015 at 13:38, Amit Kapila <[email protected]> wrote:
> On Wed, Nov 11, 2015 at 11:40 PM, Pavel Stehule <[email protected]>
> 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?
e.g.
# explain (analyse, buffers, timing, verbose, costs) select count(*)
from js where content->'tags'->>'title' like '%de%';
QUERY
PLAN
--------------------------------------------------------------------------------------------------------------------------------------
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?
Thom
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
