Re: Bitmap scan cost model (was Re: bitmap scans, btree scans, and tid order)

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

Browse pgsql-hackers by date

  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