Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id 20210505182546.s5hoimwtfsgfj7tl@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: MaxOffsetNumber for Table AMs  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Hi,

On 2021-05-05 10:56:56 -0700, Jeff Davis wrote:
> On Wed, 2021-05-05 at 10:48 -0700, Peter Geoghegan wrote:
> > What we have right now has little chance of failing. It also has
> > little chance of succeeding (except for something like zheap, which
> > can presumably get by with the heapam's idea of TID).
> 
> What has little chance of succeeding? Table AMs?
> 
> And why isn't columnar an example of someting that can "get by with
> heapam's idea of TID"? I mean, it's not a perfect fit, but my primary
> complaint this whole thread is that it's undefined, not that it's
> completely unworkable.

Agreed. And we can increase the fit a good bit without needing invasive
all-over changes. With those changes often even helping heap.

E.g. tidbitmap.c's harcoded use of MaxHeapTuplesPerPage is a problem
even for heap - we waste a lot of space that's not commonly used. A
better datastructure (radix tree like I'd say, but several tree shaped
approaches seem possible).

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs
Следующее
От: Andres Freund
Дата:
Сообщение: Re: RFC: Detailed reorder buffer stats dumps