Re: bitmap scans, btree scans, and tid order - Mailing list pgsql-hackers

From Jeffrey W. Baker
Subject Re: bitmap scans, btree scans, and tid order
Date
Msg-id 1116268955.9920.23.camel@toonses.gghcwest.com
Whole thread Raw
In response to Re: bitmap scans, btree scans, and tid order  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2005-05-16 at 14:35 -0400, Tom Lane wrote:
> "Jeffrey W. Baker" <jwbaker@acm.org> writes:
> > It's also possible that changing the btree scan to work in
> > groups of tuples instead of single tuples would make more sense, which
> > is why I ventured two different solution to the problem.
> 
> My feeling is that that would add a lot of complexity for dubious win.
> The reason it's dubious is that it would penalize some cases, for
> instance LIMIT-type queries where you aren't going to fetch many tuples
> anyway.  I think that at least for the time being (8.1 time frame) we
> should leave traditional indexscans alone and concentrate on being sure
> we are getting the most we can out of the new bitmap scan code.  Only
> after that dust has settled will we have hard facts with which to argue
> about whether compromise behaviors might be wins.

I agree.  I'll look at how my workload behaves with CVS code.  I wasn't
proposing this for 8.1 inclusion, and the TODO isn't marked for 8.1.

> I think the work that's most needed at the moment is to test the
> bitmap-scan cost model to see if it has much to do with reality...

Alright.

-jwb


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: pgFoundry
Next
From: Tom Lane
Date:
Subject: Re: pgFoundry