| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dave Cramer <davecramer(at)postgres(dot)rocks> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL Limits: maximum number of columns in SELECT result |
| Date: | 2022-05-31 14:49:44 |
| Message-ID: | 176542.1654008584@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dave Cramer <davecramer(at)postgres(dot)rocks> writes:
> On Tue, 31 May 2022 at 10:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-05-31 14:51:25 | Re: PG15 beta1 sort performance regression due to Generation context change |
| Previous Message | Ranier Vilela | 2022-05-31 14:36:28 | Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) |