On Tue, Nov 12, 2024 at 10:14 PM Masahiro Ikeda
wrote:
> On 2024-11-13 00:55, Peter Geoghegan wrote:
> > The wrapper function has extra assertions, compared to what we do
> > already. It's slightly more defensive, and IMV slightly clearer.
>
> Thanks, I agree with adding the function for refactori
On 2024-11-13 00:55, Peter Geoghegan wrote:
On Sun, Nov 10, 2024 at 11:36 PM Masahiro Ikeda
wrote:
Thanks! The change made it easier for me to understand.
As follow-up to all of the recent work in this area, I'd like to add
this wrapper function to return the next item from so->currPos.
The
On Sun, Nov 10, 2024 at 11:36 PM Masahiro Ikeda
wrote:
> Thanks! The change made it easier for me to understand.
As follow-up to all of the recent work in this area, I'd like to add
this wrapper function to return the next item from so->currPos.
The wrapper function has extra assertions, compare
On 2024-11-11 12:19, Peter Geoghegan wrote:
On Sun, Nov 10, 2024 at 9:53 PM Masahiro Ikeda
wrote:
I understand, thanks to your explanation.
Cool.
Now, there is a case where _bt_readnextpage() calls
_bt_parallel_seize(),
_bt_readpage() sets so->needPrimScan=true, and _bt_parallel_done() is
c
On Sun, Nov 10, 2024 at 9:53 PM Masahiro Ikeda wrote:
> I understand, thanks to your explanation.
Cool.
> Now, there is a case where _bt_readnextpage() calls
> _bt_parallel_seize(),
> _bt_readpage() sets so->needPrimScan=true, and _bt_parallel_done() is
> called
> with so->needPrimScan=true. Pri
On 2024-11-09 03:40, Peter Geoghegan wrote:
On Fri, Nov 8, 2024 at 8:25 AM Masahiro Ikeda
wrote:
Since I couldn't understand the reason, I have a question: is the
following deletion related to this change?
@@ -770,7 +785,7 @@ _bt_parallel_done(IndexScanDesc scan)
/*
* Shoul
On Fri, Nov 8, 2024 at 8:25 AM Masahiro Ikeda wrote:
> Thank you! I've confirmed that the v2 patch fixed the bug. As you
> mentioned, I also feel that the v2 patch is now easier to understand.
Great. I pushed something quite similar to v2 just now. Thanks!
> Since I couldn't understand the reaso
On 2024-11-08 07:42, Peter Geoghegan wrote:
Attached revision v2 pushes the fix further in this direction. It
explicitly documents that parallel _bt_readnextpage callers are
allowed to use their so->currPos state (including
blkno/nextPage/prevPage) to help _bt_readnextpage to decide whether it
ca
On Thu, Nov 7, 2024 at 2:19 PM Peter Geoghegan wrote:
> It would be weird to depend on the
> currPos state from the last _bt_readpage call, even after seizing the
> scan for the next page in line. If the scan has already finished
> (according to moreLeft/moreRight), then why even try to seize the
On Thu, Nov 7, 2024 at 5:44 AM Masahiro Ikeda
wrote:0-12 08:29, Peter Geoghegan wrote:
> > On Thu, Oct 10, 2024 at 1:41 PM Peter Geoghegan wrote:
> > * We now reset currPos state (including even its moreLeft/moreRight
> > fields) within _bt_parallel_seize, automatically and regardless of any
> >
Hi, thanks for working on these improvements.
I noticed an unexpected behavior where the index scan continues instead
of
stopping, even when it detects that there are no tuples that match the
conditions.
(I observed this while reviewing the skip scan patch, though it isn't
directly
related to
On Thu, Oct 17, 2024 at 5:13 PM Matthias van de Meent
wrote:
> I'm a little bit concerned about this change: I'm not familiar with
> predicate locks, PLP, or anything related to SSI, but previously we
> called PLP in parallel scans while we still had hold of the scan,
> while we now call PLP only
On Wed, 16 Oct 2024 at 20:03, Peter Geoghegan wrote:
>
> On Fri, Oct 11, 2024 at 7:29 PM Peter Geoghegan wrote:
> > Attached is v5
>
> Now I'm attaching a v6, which further polishes things. Current plan is to
> commit something very close to this in the next day or two.
>
> v6 is mostly just furt
On Fri, Oct 11, 2024 at 7:29 PM Peter Geoghegan wrote:
> Attached is v5
Now I'm attaching a v6, which further polishes things. Current plan is to
commit something very close to this in the next day or two.
v6 is mostly just further comment polishing. But it also merges together
the two existing
On Thu, Oct 10, 2024 at 1:41 PM Peter Geoghegan wrote:
> The main simplification new to v4 is that v4 isolates the need to call
> _bt_drop_lock_and_maybe_pin to only 2 functions: _bt_readnextpage, and
> its new _bt_readfirstpage "sibling" function. The functions have
> similar preconditions, and i
On Tue, Oct 8, 2024 at 12:52 PM Peter Geoghegan wrote:
> The code in v3-0001-Avoid-unneeded-nbtree-backwards-scan-buffer-locks.patch
> looks reasonable to me. I don't think that there are any impediments
> to committing it sometime this week.
I see significant benefits for parallel index-only bac
On Fri, Jul 5, 2024 at 12:47 PM Peter Geoghegan wrote:
> On HEAD, the following query requires 24 buffer hits (I'm getting a
> standard/forward index scan for this):
>
> select
> abalance
> from
> pgbench_accounts
> where
> aid in (1, 500, 1000, 1500, 2000, 3000) order by aid asc;
>
> Howeve
On Mon, Sep 02, 2024 at 01:31:55PM +0200, Matthias van de Meent wrote:
> I noticed I attached an older version of the patch which still had 1
> assertion failure case remaining (thanks cfbot), so here's v3 which
> solves that problem.
Peter G., this is in your area of expertise. Could you look at
On Fri, 30 Aug 2024 at 21:43, Matthias van de Meent
wrote:
>
> On Mon, 19 Aug 2024 at 13:43, Matthias van de Meent
> wrote:
> >
> > On Sun, 11 Aug 2024 at 21:44, Peter Geoghegan wrote:
> > >
> > > On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent
> > > wrote:
> > > > +1, LGTM.
> > > >
> > >
On Mon, 19 Aug 2024 at 13:43, Matthias van de Meent
wrote:
>
> On Sun, 11 Aug 2024 at 21:44, Peter Geoghegan wrote:
> >
> > On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent
> > wrote:
> > > +1, LGTM.
> > >
> > > This changes the backward scan code in _bt_readpage to have an
> > > approximate
On Sun, 11 Aug 2024 at 21:44, Peter Geoghegan wrote:
>
> On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent
> wrote:
> > +1, LGTM.
> >
> > This changes the backward scan code in _bt_readpage to have an
> > approximately equivalent handling as the forward scan case for
> > end-of-scan cases, whi
On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent
wrote:
> +1, LGTM.
>
> This changes the backward scan code in _bt_readpage to have an
> approximately equivalent handling as the forward scan case for
> end-of-scan cases, which is an improvement IMO.
Pushed just now. Thanks for the review!
--
On Fri, 5 Jul 2024 at 18:48, Peter Geoghegan wrote:
>
> Attached patch teaches nbtree backwards scans to avoid needlessly
> relocking a previously read page/buffer at the point where we need to
> consider reading the next page (the page to the left).
+1, LGTM.
This changes the backward scan code
Attached patch teaches nbtree backwards scans to avoid needlessly
relocking a previously read page/buffer at the point where we need to
consider reading the next page (the page to the left).
Currently, we do this regardless of whether or not we already decided
to end the scan, back when we read th
24 matches
Mail list logo
