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
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, .
,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
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
