From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PATCH: Using BRIN indexes for sorted output |
Date: | 2023-02-24 16:11:21 |
Message-ID: | CAEze2WjXHXcfK+SRi3pwkXounPrrW=GM62-pOBrnHOAAivoKXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 24 Feb 2023 at 17:04, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> On 2/24/23 16:14, Alvaro Herrera wrote:
> > ... if pagesPerRange is not a whole divisor of MaxBlockNumber, I think
> > this will neglect the last range in the table.
> >
>
> Why would it? Let's say BlockNumber is uint8, i.e. 255 max. And there
> are 10 pages per range. That's 25 "full" ranges, and the last range
> being just 5 pages. So we get into
>
> prevHeapBlk = 240
> heapBlk = 250
>
> and we read the last 5 pages. And then we update
>
> prevHeapBlk = 250
> heapBlk = (250 + 10) % 255 = 5
>
> and we don't do that loop. Or did I get this wrong, somehow?
The result is off-by-one due to (u)int8 overflows being mod-256, but
apart from that your result is accurate.
The condition only stops the loop when we wrap around or when we go
past the last block, but no earlier than that.
Kind regards,
Matthias van de Meent
From | Date | Subject | |
---|---|---|---|
Next Message | Sébastien Lardière | 2023-02-24 16:27:21 | Re: Timeline ID hexadecimal format |
Previous Message | Tomas Vondra | 2023-02-24 16:04:17 | Re: PATCH: Using BRIN indexes for sorted output |