Re: PATCH: Using BRIN indexes for sorted output
От | Alvaro Herrera |
---|---|
Тема | Re: PATCH: Using BRIN indexes for sorted output |
Дата | |
Msg-id | 20230301183301.w3m5f2fbovm5hv5c@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: PATCH: Using BRIN indexes for sorted output (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Список | pgsql-hackers |
On 2023-Feb-24, Tomas Vondra wrote: > On 2/24/23 16:14, Alvaro Herrera wrote: > > 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). > > Did anyone even propose doing that? I suspect this is unlikely to be the > only place that'd might be broken by that. True about other places also needing fixes, and no I haven't see anyone; but while 32 TB does seem very far away to us now, it might be not *that* far away. So I think doing it the other way is better. > > ... 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? I stand corrected. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: