Re: BUG #15984: order of where in() query affects query planer - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15984: order of where in() query affects query planer
Date
Msg-id 7528.1567117005@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15984: order of where in() query affects query planer  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15984: order of where in() query affects query planer  (easteregg@verfriemelt.org)
Re: BUG #15984: order of where in() query affects query planer  (easteregg@verfriemelt.org)
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15984: order of where in() query affects query planer
Next
From: easteregg@verfriemelt.org
Date:
Subject: Re: BUG #15984: order of where in() query affects query planer