postgres/timescaledb
1
0
Fork 0
mirror of https://github.com/timescale/timescaledb.git synced 2025-05-15 01:53:41 +08:00
Code Issues Packages Projects Releases Wiki Activity

Make pg_join test more deterministic

Browse Source 
The pg_join regression test is flaky. This PR adds some analyze calls
and increases the size of one table to make the test outcome more
deterministic.
This commit is contained in:
Jan Nidzwetzki 2023-09-19 10:04:07 +02:00 committed by Jan Nidzwetzki
parent a7e7e675a4
commit 8fac069be3
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
test/sql/include/join_query.sql
View File

@ -1994,9 +1994,12 @@ update pg_class
-- Make a relation with a couple of enormous tuples.
create table wide(id int, t text);
select table_name from create_hypertable('wide','id',chunk_time_interval:=5000);
insert into wide select generate_series(1, 2) as id, rpad('', 320000, 'x') as t;
insert into wide select generate_series(1, 10) as id, rpad('', 320000, 'x') as t;
alter table wide set (parallel_workers = 2);
-- update statistics
analyze wide;
-- The "optimal" case: the hash table fits in memory; we plan for 1
-- batch, we stick to that number, and peak memory usage stays within
-- our work_mem budget
@ -2211,6 +2214,10 @@ alter table join_foo set (parallel_workers = 0);
create table join_bar as select generate_series(1, 10000) as id, 'xxxxx'::text as t;
alter table join_bar set (parallel_workers = 2);
-- update statistics
analyze join_foo;
analyze join_bar;
-- multi-batch with rescan, parallel-oblivious
savepoint settings;
set enable_parallel_hash = off;