From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, 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 15:14:16 |
Message-ID: | 20230224151416.waqpi5syn36hun2l@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-Feb-24, Tomas Vondra wrote:
> I guess the easiest fix would be to do the arithmetic in 64 bits. That'd
> eliminate the overflow.
Yeah, that might be easy to set up. We then don't have to worry about
it until BlockNumber is enlarged to 64 bits ... but by that time surely
we can just grow it again to a 128 bit loop variable.
> Alternatively, we could do something like
>
> prevHeapBlk = 0;
> for (heapBlk = 0; (heapBlk < nblocks) && (prevHeapBlk <= heapBlk);
> heapBlk += pagesPerRange)
> {
> ...
> prevHeapBlk = heapBlk;
> }
I think a formulation of this kind has the benefit that it works after
BlockNumber is enlarged to 64 bits, and doesn't have to be changed ever
again (assuming it is correct).
... if pagesPerRange is not a whole divisor of MaxBlockNumber, I think
this will neglect the last range in the table.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-24 15:19:04 | Re: Stale references to guc.c in comments/tests |
Previous Message | Peter Eisentraut | 2023-02-24 15:03:29 | Re: pgindent vs. git whitespace check |