hubert depesz lubaczewski <depesz@xxxxxxxxxx> writes: > I solved the problem by adding "enable_bitmapscan = false" (and keeping > the query in original format, with subselect) which caused the plan to > be ok. I doubt that solution is any more robust than what you had before --- in particular, it's likely to fall back to seqscans. > but I'm much more interested to understand why pg chooses *not* to use > index which is tailored specifically for the query - it has exactly > matching where clause, and it indexes the column that we use for > comparison. Because the planner thinks it will have to pull a huge number of rows from the index. Whether the index is "tailored" for the query is irrelevant if it looks more expensive to use than a seqscan. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
