> > Did it actually use a parallel plan in your testing?
> > When I ran these tests with the Parallel INSERT patch applied, it did
> > not naturally choose a parallel plan for any of these cases.
>
> Yes, these cases pick parallel plan naturally on my test environment.
>
> postgres=# explain verbose insert into testscan select a from x where
> a<80000 or (a%2=0 and a>199900000);
> QUERY PLAN
> ----------------------------------------------------------------------
> -----------------------------
> Gather (cost=4346.89..1281204.64 rows=81372 width=0)
> Workers Planned: 4
> -> Insert on public.testscan (cost=3346.89..1272067.44 rows=0
> width=0)
> -> Parallel Bitmap Heap Scan on public.x1
> (cost=3346.89..1272067.44 rows=20343 width=8)
> Output: x1.a, NULL::integer
> Recheck Cond: ((x1.a < 80000) OR (x1.a > 199900000))
> Filter: ((x1.a < 80000) OR (((x1.a % 2) = 0) AND (x1.a >
> 199900000)))
> -> BitmapOr (cost=3346.89..3346.89 rows=178808
> width=0)
> -> Bitmap Index Scan on x1_a_idx
> (cost=0.00..1495.19 rows=80883 width=0)
> Index Cond: (x1.a < 80000)
> -> Bitmap Index Scan on x1_a_idx
> (cost=0.00..1811.01 rows=97925 width=0)
> Index Cond: (x1.a > 199900000)
>
> PSA is my postgresql.conf file, maybe you can have a look. Besides, I didn't
> do any parameters tuning in my test session.
I reproduced this on my machine.
I think we'd better do "analyze" before insert which helps reproduce this easier.
Like:
-----
analyze;
explain analyze verbose insert into testscan select a from x where a<80000 or (a%2=0 and a>199900000);
-----
Best regards,
houzj