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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Non-superuser subscription owners
Следующее
От: Greg S
Дата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel