can't be parallelized? Or is
there some other way I could structure the query to get it to use
parallelism?
I've tried this both on PG 15.1 (In docker, which seems to be on Debian
15.1) and PG 14.5 (on Centos 7) an
,4654284,3558460]::integer[]);
QUERY PLAN
Index Scan using testing_pkey on testing (cost=0.43..6138.81 rows=1000
width=74)
Index Cond: (id = ANY ('{1608377,5449811, ... < removed for brevity >
... 4654284,3558460}'::integer[]))
(2 rows)
Thanks
testing_pkey on testing (cost=0.43..8.37
rows=1 width=74)
Index Cond: (id = ids.probe_id)
(6 rows)
Thanks,
Alex Kaiser
On Wed, Feb 1, 2023 at 1:52 PM Thomas Munro wrote:
> On Wed, Feb 1, 2023 at 6:39 PM Alex Kaiser wrote:
> > select * from testing where id in (1608377,5449811, .
27;t
really care about the few extra wasted CPU cycles. But I can't actually do
this as I can't set parallel_setup_costs to be negative, so I wouldn't be
able to get PG to choose the parallel plan even if I did partition the
table.
> If I had more timerons myself ...
If only we a
