Re: Bitmap table scan cost per page formula - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Bitmap table scan cost per page formula
Date
Msg-id CAMkU=1whYV+L_SJDr8Hw1a3TtFrzP9+r_Ee3SegSm_-v58VkUQ@mail.gmail.com
Whole thread Raw
In response to Re: Bitmap table scan cost per page formula  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 20, 2017 at 5:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The parabola is probably wrong in detail --- its behavior as we approach
reading all of the pages ought to be more asymptotic, seems like.
I suppose that the reason it appears to go below the seqscan cost at the
right is that even the rightmost end of the curve doesn't reflect reading
all of the *tuples*, just one tuple per page, so that there's some CPU
savings from not inspecting all the tuples. 

I think that the graph is only about the IO costs of the heap scan, and the CPU costs are an independent issue.  

The reason it drops below the seqscan on the far right edge is much simpler.  10,000 is the point where 100% of the pages are being read, so the two scans converge to the same value.  The graph continues above 10,000 but it is meaningless as a bitmap heap scan will never read more than 100% of the table pages and so the math no longer represents a reality.
 
Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Bitmap table scan cost per page formula
Next
From: Pavel Stehule
Date:
Subject: Re: domain cast in parameterized vs. non-parameterized query