Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 20210505182546.s5hoimwtfsgfj7tl@alap3.anarazel.de
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MaxOffsetNumber for Table AMs
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: MaxOffsetNumber for Table AMs
Next
From: Andres Freund
Date:
Subject: Re: RFC: Detailed reorder buffer stats dumps