Re: bitmap scans, btree scans, and tid order - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bitmap scans, btree scans, and tid order
Date
Msg-id 17173.1116251610@sss.pgh.pa.us
Whole thread Raw
In response to Re: bitmap scans, btree scans, and tid order  (Jeffrey Baker <jwbaker@acm.org>)
List pgsql-hackers
Jeffrey Baker <jwbaker@acm.org> writes:
> Change the planner/executor to use the bitmap scan in all cases where 
> index order is unimportant.  From my reading of the current code, the 
> bitmap scan is only used in case of a join.

This is a fallacy, and I think your concern is largely mistaken.  Have
you experimented with the cases you are worried about?

It's entirely possible that the current cost model needs adjustment to
make the planner pick the bitmap scan in more cases.  However, it is
easy to demonstrate (either by thought-experiment or actual trial) that
a bitmap scan isn't necessarily a win.  The overhead of maintaining the
bitmap is far from zero, and you don't get anything unless the resulting
pattern of heap page fetches is significantly cleaner than before.
Therefore, a patch that eliminates cost-estimation in favor of trying to
force one choice or the other is definitely not likely to be received
favorably ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cost of XLogInsert CRC calculations
Next
From: Hannu Krosing
Date:
Subject: Re: SQL Request Size