timescaledb/test/sql/parallel.sql.in
Sven Klemm fce3d08638 Make constraint aware append parallel safe
Constraint aware append used some planner data structures in the
executor which cannot be serialized so they will not be available
in parallel workers, this patch refactors this and marks the
constraint aware append node as parallel safe when the subpath is
parallel safe. The additional function executions in the test output
are because the constify is run once per chunk now, previously it run
only once and the result was copied to the restrictinfo of every chunk
and then adjusted for the chunk, but since the adjustment for the chunk
has to happen in the planner because it needs access to appendrelinfo
we now create per chunk restrictinfo in the planner and constify each of
these in the executor.

On PostgreSQL < 12 now() is not parallel safe and using now() in a
query will prevent parallelism. As a workaround transaction_timestamp()
or CURRENT_TIMESTAMP can be used which will not prevent parallelism.
2019-02-22 15:31:56 -05:00

79 lines
2.7 KiB
MySQL

-- This file and its contents are licensed under the Apache License 2.0.
-- Please see the included NOTICE for copyright information and
-- LICENSE-APACHE for a copy of the license.
--parallel queries require big-ish tables so collect them all here
--so that we need to generate queries only once.
-- look at postgres version to decide whether we run with analyze or without
SELECT
CASE WHEN current_setting('server_version_num')::int >= 100000
THEN 'EXPLAIN (analyze, costs off, timing off, summary off)'
ELSE 'EXPLAIN (costs off)'
END AS "PREFIX"
\gset
CREATE TABLE test (i int, j double precision, ts timestamp);
SELECT create_hypertable('test','i',chunk_time_interval:=500000);
--has to be big enough to force at least 2 workers below.
INSERT INTO test SELECT x, x+0.1, _timescaledb_internal.to_timestamp(x*1000) FROM generate_series(0,1000000-1) AS x;
SET client_min_messages = 'error';
--avoid warning polluting output
ANALYZE;
RESET client_min_messages;
SET work_mem TO '50MB';
SET force_parallel_mode = 'on';
SET max_parallel_workers_per_gather = 4;
:PREFIX SELECT first(i, j) FROM "test";
SELECT first(i, j) FROM "test";
:PREFIX SELECT last(i, j) FROM "test";
SELECT last(i, j) FROM "test";
-- we dont run this with analyze because the sort memory usage is not stable
EXPLAIN (costs off) SELECT time_bucket('1 second', ts) sec, last(i, j)
FROM "test"
GROUP BY sec
ORDER BY sec
LIMIT 5;
SELECT time_bucket('1 second', ts) sec, last(i, j)
FROM "test"
GROUP BY sec
ORDER BY sec
LIMIT 5;
--test variants of histogram
EXPLAIN (costs off) SELECT histogram(i, 1, 1000000, 2) FROM "test";
SELECT histogram(i, 1, 1000000, 2) FROM "test";
EXPLAIN (costs off) SELECT histogram(i, 1,1000001,10) FROM "test";
SELECT histogram(i, 1, 1000001, 10) FROM "test";
EXPLAIN (costs off) SELECT histogram(i, 0,100000,5) FROM "test";
SELECT histogram(i, 0, 100000, 5) FROM "test";
EXPLAIN (costs off) SELECT histogram(i, 10,100000,5) FROM "test";
SELECT histogram(i, 10, 100000, 5) FROM "test";
-- test constraint aware append
:PREFIX SELECT i FROM "test" WHERE length(version()) > 0;
-- test constraint aware append with parallel aggregation
:PREFIX SELECT count(*) FROM "test" WHERE length(version()) > 0;
SELECT count(*) FROM "test" WHERE length(version()) > 0;
-- now() is not marked parallel safe in PostgreSQL < 12 so using now()
-- in a query will prevent parallelism but CURRENT_TIMESTAMP and
-- transaction_timestamp() are marked parallel safe
:PREFIX SELECT i FROM "test" WHERE ts < CURRENT_TIMESTAMP;
:PREFIX SELECT i FROM "test" WHERE ts < transaction_timestamp();
-- this won't be parallel query because now() is parallel restricted in PG < 12
:PREFIX SELECT i FROM "test" WHERE ts < now();