On 25/04/2019 10:55, Alvaro Herrera wrote:
> On 2019-Apr-24, pabloa98 wrote:
>
>> Regarding to (2), We are good by adding a patch and recompile a patched
>> version for our server databases.
>>
>> But we are open on helping to add thousands of columns support as a
>> compile-time parameter if there are other people interested.
> It's hard to say what you're doing wrong when we don't know
> what are you actually doing.
>
> I think raising the limit requires changing ItemIdData, t_hoff, and a
> few members of PageHeaderData at the very least. Reading the three
> header files involved carefully would probably point out areas I've
> forgotten to mention. I think if you enlarge t_hoff and lp_off/lp_len
> to 16 bits, you can use 64kB blocks, which might be useful too.
>
> Note that with pg12 you could have your own table AM that supported
> wider ItemIds as a (small?) change on heapam, rather than supplant it
> for all tables. That way you would only pay the (probably considerable)
> cost of the wider line pointers on all tables ...
>
I wonder if it might prove a killer feature for some niche uses!
Stranger things have come to pass.
Suspect that going beyond 1600 columns would never be the default, even
if the pg core devs, were happy to allow it as an official option
(presumably at compile time?). As I think it would have negative
performance impacts on the most uses of pg - as Alvaro hinted at. IMnsHO
Certainly the will be many people intrigued as to what you are trying to
do, even if we never want to do the same ourselves.