From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | parallel explain analyze support not exercised |
Date: | 2017-03-31 18:55:41 |
Message-ID: | 20170331185540.zmsue4ndvqtnayqw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
As visible in [1], the explain analyze codepaths of parallel query isn't
exercised in the tests. That used to be not entirely trivial if the
output was to be displayed (due to timing), but we should be able to do
that now that we have the SUMMARY option.
E.g.
SET max_parallel_workers = 0;
EXPLAIN (analyze, timing off, summary off, costs off) SELECT * FROM blarg2 WHERE generate_series < 0;
┌───────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├───────────────────────────────────────────────────────────┤
│ Gather (actual rows=0 loops=1) │
│ Workers Planned: 10 │
│ Workers Launched: 0 │
│ -> Parallel Seq Scan on blarg2 (actual rows=0 loops=1) │
│ Filter: (generate_series < 0) │
│ Rows Removed by Filter: 10000000 │
└───────────────────────────────────────────────────────────┘
should be reproducible. I'd suggest additionally adding one tests that
throws the EXPLAIN output away, but actually enables paralellism.
Greetings,
Andres Freund
[1] https://coverage.postgresql.org/src/backend/executor/execParallel.c.gcov.html
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-31 19:00:10 | Re: Somebody has not thought through subscription locking considerations |
Previous Message | Tom Lane | 2017-03-31 18:54:40 | Re: Allow to specify #columns in heap/index_form_tuple |