"Steinar H. Gunderson" <sgunderson@xxxxxxxxxxx> writes: > What about the working set? Have you tried running the queries multiple times > in a row to see if the results change? It might be that your initial bitmap > scan puts all the relevant bits into cache, which will skew the results. If the examples were done in the order shown, the seqscan ought to have pretty well blown out the cache ... but I concur that it'd be interesting to check whether repeated executions of the same plan show markedly different times. Also, is the index order closely correlated to the actual physical table order? What is work_mem set to, and does increasing it substantially make the bitmap scan work any better? Considering that the query is fetching about half of the table, I'd have thought that the planner was correct to estimate that bitmap or seqscan ought to win. For the plain indexscan to win, the order correlation must be quite strong, and I'm also guessing that the bitmap scan must have run into some substantial trouble (like discarding a lot of info because of lack of work_mem). IIRC, the planner doesn't currently try to model the effects of a bitmap scan going into lossy mode, which is something it probably should try to account for. regards, tom lane
