From: | "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Manfred Koizar" <mkoi-pg(at)aon(dot)at>, "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order) |
Date: | 2005-05-19 10:45:37 |
Message-ID: | E1539E0ED7043848906A8FF995BDA5790C516F@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas DAZ SD | 2005-05-19 11:56:36 | Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order) |
Previous Message | Oleg Bartunov | 2005-05-19 09:39:31 | Re: understanding bitmap index benefit |