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

From Zeugswetter Andreas DAZ SD
Subject Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order)
Date
Msg-id E1539E0ED7043848906A8FF995BDA5790C516F@m0143.s-mxs.net
Whole thread Raw
List pgsql-hackers
> >Incrementing random_page_cost from 4 (the default) to 5 causes the
> >planner to make a better decision.
>
> We have such a low default random_page_cost primarily to mask other
> problems in the optimizer, two of which are
>
> . multi-column index correlation
>
> . interpolation between min_IO_Cost and max_IO_cost which approximates
> max_IO_cost too fast.

One other important figure here is concurrency. If you have a lot of backends
concurrently doing other IO, your sequential IO numbers will suffer more than
random IO numbers. Might be, that some super smart OS readahead implementation
aleviates that problem, but I have not yet experienced one.
Also less of random IO tends to get higher cache rates.

Thus I think if you are alone, 4 tends to be too low, while with concurrent load
4 tends to be too high. (All assuming farly large tables, that don't fit into RAM)

Andreas


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: understanding bitmap index benefit
Next
From: "Zeugswetter Andreas DAZ SD"
Date:
Subject: Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order)