Thanks for your answer! And I am sorry for trading the question as a bug, and
send it to 'bugs' mailing-list.
But I doubt your answer. I think the essence of the problem is when the planner
selects 'Bitmap Index Scan' and how the planner computes the cost of 'Bitmap
Index Scan'.
Tom Lane said “In principle a bitmap index scan should be significantly faster
if the index can return the bitmap more or less "natively" rather than having
to construct it. My recollection though is that a significant amount of work is
needed to make that happen, and that there is no existing patch that tackled
the problem. So I'm not sure that this report should be taken as indicating
that there's no chance of a SELECT performance improvement. What it does say is
that we have to do that work if we want to make bitmap indexes useful.”
Okay, I want to know how the planner computes the cost of constructing bitmap.
And when the planner computes the cost of 'Bitmap Index Scan', if it considers
the influence of memory cache? As when I do not clear the memory cache, I find
the 'Bitmap Index Scan' is real fast than 'Seq Scan'.
Best Regards!
Asen
