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

2021-04-14 Thread Dmitry Koterov
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

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

2021-04-14 Thread Michael Lewis
Your query and explain analyze output do not seem to match. Filter: (cred_id = '1001344096118566254'::bigint) I don't see anything like that in your query, nor an index that would support accomplishing that without filtering after fetching the 184k rows initially like the planner does. >