Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order)
Date
Msg-id 22075.1116430058@sss.pgh.pa.us
Whole thread Raw
In response to Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order)  ("Jeffrey W. Baker" <jwbaker@acm.org>)
Responses Re: Bitmap scan cost model (was Re: bitmap scans, btree  ("Jeffrey W. Baker" <jwbaker@acm.org>)
List pgsql-hackers
"Jeffrey W. Baker" <jwbaker@acm.org> writes:
> ... If bitmap
> scan is disabled, the planner will pick index scan even in cases when
> sequential scan is 10x faster:

> scratch=# set enable_bitmapscan to off;
> SET
> scratch=# explain analyze select count(1) from test where random >= 1429076987  and  random < 1429076987 + 10000000;
>                                                                  QUERY PLAN
                    
 
>
--------------------------------------------------------------------------------------------------------------------------------------------
>  Aggregate  (cost=170142.03..170142.03 rows=1 width=0) (actual time=177419.182..177419.185 rows=1 loops=1)
>    ->  Index Scan using test_rand_idx on test  (cost=0.00..170034.11 rows=43167 width=0) (actual
time=0.035..177255.696rows=46764 loops=1)
 
>          Index Cond: ((random >= 1429076987) AND (random < 1439076987))
>  Total runtime: 177419.302 ms
> (4 rows)

> scratch=# set enable_indexscan to off;
> SET
> scratch=# explain analyze select count(1) from test where random >= 1429076987  and  random < 1429076987 + 10000000;
>                                                       QUERY PLAN

>
----------------------------------------------------------------------------------------------------------------------
>  Aggregate  (cost=204165.55..204165.55 rows=1 width=0) (actual time=12334.042..12334.045 rows=1 loops=1)
>    ->  Seq Scan on test  (cost=0.00..204057.62 rows=43167 width=0) (actual time=17.436..12174.150 rows=46764
loops=1)
>          Filter: ((random >= 1429076987) AND (random < 1439076987))
>  Total runtime: 12334.156 ms
> (4 rows)

> Obviously in this case sequential scan was (would have been) a huge win.
> Incrementing random_page_cost from 4 (the default) to 5 causes the
> planner to make a better decision.

But to get the estimated cost ratio to match up with the actual cost
ratio, we'd have to raise random_page_cost to nearly 70, which is a bit
hard to credit.  What was the platform being tested here?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: SO_KEEPALIVE
Next
From: Greg Stark
Date:
Subject: Re: Learning curves and such (was Re: pgFoundry)