Re: BUG #15984: order of where in() query affects query planer

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> i have a partial index like in the following example and when reorder the
> elements of the in() statement,
> i get sometimes a bitmap indexscan instead of the expected index only scan.
> if i remove an element, i still get the index only,
> but with the wrong order, i get a bitmap heap scan. is this expected?

FWIW, I get the same plan shape with either order of the IN elements.

However, your example is probably going to be subject to plan instability
because

(1) you used vacuum full not plain vacuum. That doesn't leave the table
in the all-visible condition that would favor an index-only scan.

(2) you didn't analyze the table. At some point, autovacuum will come
along and rectify that oversight, likely causing the plan choice to
change underneath you.

regards, tom lane