From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Subject: | Re: BitmapHeapScan streaming read user and prelim refactoring |
Date: | 2024-02-27 01:50:28 |
Message-ID: | 20240227015028.knohvy3spaqwk7lf@liskov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 16, 2024 at 12:35:59PM -0500, Melanie Plageman wrote:
> In the attached v3, I've reordered the commits, updated some errant
> comments, and improved the commit messages.
>
> I've also made some updates to the TIDBitmap API that seem like a
> clarity improvement to the API in general. These also reduce the diff
> for GIN when separating the TBMIterateResult from the
> TBM[Shared]Iterator. And these TIDBitmap API changes are now all in
> their own commits (previously those were in the same commit as adding
> the BitmapHeapScan streaming read user).
>
> The three outstanding issues I see in the patch set are:
> 1) the lossy and exact page counters issue described in my previous
> email
I've resolved this. I added a new patch to the set which starts counting
even pages with no visible tuples toward lossy and exact pages. After an
off-list conversation with Andres, it seems that this omission in master
may not have been intentional.
Once we have only two types of pages to differentiate between (lossy and
exact [no longer have to care about "has no visible tuples"]), it is
easy enough to pass a "lossy" boolean paramater to
table_scan_bitmap_next_block(). I've done this in the attached v4.
- Melanie
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2024-02-27 02:01:55 | Re: Better error messages for %TYPE and %ROWTYPE in plpgsql |
Previous Message | Andy Fan | 2024-02-27 01:49:00 | Re: Better error messages for %TYPE and %ROWTYPE in plpgsql |