Re: BitmapHeapScan streaming read user and prelim refactoring - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: BitmapHeapScan streaming read user and prelim refactoring
Date
Msg-id 20240323002607.abegehmmjyxrnmm2@liskov
Whole thread Raw
In response to Re: BitmapHeapScan streaming read user and prelim refactoring  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: BitmapHeapScan streaming read user and prelim refactoring
List pgsql-hackers
On Fri, Mar 22, 2024 at 08:22:11PM -0400, Melanie Plageman wrote:
> On Tue, Mar 19, 2024 at 02:33:35PM +0200, Heikki Linnakangas wrote:
> > On 18/03/2024 17:19, Melanie Plageman wrote:
> > > I've attached v7 rebased over this commit.
> > 
> > If we delayed table_beginscan_bm() call further, after starting the TBM
> > iterator, we could skip it altogether when the iterator is empty.
> > 
> > That's a further improvement, doesn't need to be part of this patch set.
> > Just caught my eye while reading this.
> 
> Hmm. You mean like until after the first call to tbm_[shared]_iterate()?
> AFAICT, tbm_begin_iterate() doesn't tell us anything about whether or
> not the iterator is "empty". Do you mean cases when the bitmap has no
> blocks in it? It seems like we should be able to tell that from the
> TIDBitmap.
> 
> > 
> > > v7-0003-Push-BitmapHeapScan-skip-fetch-optimization-into-.patch
> > 
> > I suggest to avoid the double negative with SO_CAN_SKIP_FETCH, and call the
> > flag e.g. SO_NEED_TUPLE.
> 
> Agreed. Done in attached v8. Though I wondered if it was a bit weird
> that the flag is set in the common case and not set in the uncommon
> case...

v8 actually attached this time

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pg_upgrade --copy-file-range
Next
From: Thomas Munro
Date:
Subject: Re: Cannot find a working 64-bit integer type on Illumos