From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: More thoughts about planner's cost estimates |
Date: | 2006-06-02 02:32:10 |
Message-ID: | 23364.1149215530@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> Tom Lane wrote:
>> With this model, the disk cost to fetch a single
>> index entry will be estimated as random_page_cost (default 4.0) rather
>> than the current fixed 2.0. This shouldn't hurt things too much for
>> simple indexscans --- especially since anyone running with a reduced
>> random_page_cost won't see as much change. And it will increase the costs
>> for bitmap scans that cross many index pages, which is what we need in
>> light of Philippe's numbers.
> This sounds good to me, although the 2.0 -> 4.0 cost jump may cause
> (more) cases of people seeing their index scans in pre-8.2 versions
> becoming some other type of access in 8.2. I guess a comment about
> testing existing applications could be placed in the 8.2 release notes?
Yeah, that comes with the territory. One point to note is that with
this model, setting random_page_cost below 2.0 will actually make small
indexscans look *cheaper* than they do now. So it'll certainly be
possible to make the thing jump in that direction if you need to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-02 02:35:31 | Re: 'CVS-Unknown' buildfarm failures? |
Previous Message | Andrew Dunstan | 2006-06-02 02:31:01 | Re: 'CVS-Unknown' buildfarm failures? |