On Fri, 23 Aug 2024 at 01:14, PG Bug reporting form
<noreply@postgresql.org> wrote:
> set min_parallel_index_scan_size to '8kB';
>
> set min_parallel_table_scan_size to '8kB';
> set parallel_tuple_cost to 0;
> set parallel_setup_cost to 0;
>
> have no effect.
>
> Even with the set force_parallel_mode to on - no effect:
> negotiation_chat_archive=# explain analyze select topic_id as y0_ from
> public.negotiation_topic_archive_p005 this_ where
> this_.employer_id='816144';
Does it choose a parallel plan if you do:
ALTER TABLE public.negotiation_topic_archive_p005 SET (parallel_workers = 2);
I assume it must be a btree index given the other plan does use a
parallel scan. So I wondered if something weird was happening in
compute_parallel_worker() and it was choosing 1 worker, which might
cause the path to be rejected.
You might need to come up with a self-contained test case here as when
I tried this on PG15, I do get a parallel index scan.
create table t1 (a int);
insert into t1 select x/1000 from generate_Series(1,1000000)X;
create index on t1(a);
set min_parallel_index_scan_size to '8kB';
set min_parallel_table_scan_size to '8kB';
set parallel_tuple_cost to 0;
set parallel_setup_cost to 0;
explain select * from t1 where a < 10;
QUERY PLAN
--------------------------------------------------------------------------------------------
Gather (cost=0.42..179.40 rows=8912 width=4)
Workers Planned: 2
-> Parallel Index Only Scan using t1_a_idx on t1
(cost=0.42..179.40 rows=3713 width=4)
Index Cond: (a < 10)
(4 rows)
select version();
version
-------------------------------------------------------------------------------------------------------
PostgreSQL 15.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)
David
