Re: Suboptimal plan when IN(...), ORDER BY and LIMIT are used (no JOINs)

Yeah, that was a plan for a query before its simplification. But effect is still the same, and also the question is still the same - why a bitmap scan is preferred over a number of individual index scans with fetching first 50 elements from each. (Also, replacing LIMIT 50 to LIMIT 2 doesn't seem to

Suboptimal plan when IN(...), ORDER BY and LIMIT are used (no JOINs)

Hi. I'm trying to understand the logic which the planner uses in "WHERE x IN (IDS) ORDER BY y LIMIT N" queries when the correct index exists in the database. I expected that, if IDS list is small and N is small too, the planner should've done the following: for each element in IDS, query first N