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