On Tue, 31 May 2022 at 10:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Cramer <davecramer@postgres.rocks> writes: > > On Tue, 31 May 2022 at 10:16, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> We've generally felt that the existing "columns per table" limit is > >> sufficient detail here. > > > ISTM that adding detail is free whereas the readers time to figure out > why > > and where this number came from is not. > > Detail is far from "free". Most readers are going to spend more time > wondering what the difference is between "columns per table" and "columns > per tuple", and which limit applies when, than they are going to save by > having the docs present them with two inconsistent numbers. >
Sounds to me like we are discussing different sides of the same coin. On one hand we have readers of the documentation who may be confused, and on the other hand we have developers who run into this and have to spend time digging into the code to figure out what's what. For me, while I have some familiarity with the server code it takes me quite a while to load and find what I am looking for. Then we have the less than clear names like "resno" for which I still haven't groked. So imagine someone who has no familiarity with the backend code trying to figure out why 1664 is relevant when the docs mention 1600. Surely there must be some middle ground where we can give them some clues without having to wade through the source code ? Dave
