Re: PostgreSQL Limits: maximum number of columns in SELECT result

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: PostgreSQL Limits: maximum number of columns in SELECT result
Дата
Msg-id CAB=Je-FVMvMcr_wmKcKQ9oYFY_=2CbVTVAqaeyZL=hc3cwZ2RQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Limits: maximum number of columns in SELECT result  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PostgreSQL Limits: maximum number of columns in SELECT result  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
>ost readers are going to spend more time
>wondering what the difference is between "columns per table" and "columns
>per tuple"

"tuple" is already mentioned 10 times on "limits" page, so adding "columns per tuple" is not really obscure.
The comment could be like "for instance, max number of expressions in each SELECT clause" 


I know I visited current/limits.html many times (mostly for things like "max field length")
However, I was really surprised there's an easy to hit limit on the number of expressions in SELECT.

I don't ask to lift the limit, however, I am sure documenting the limit would make it clear
for the application developers that the limit exists and they should plan for it in advance.

----

I bumped into "target lists can have at most 1664 entries" when I was trying to execute a statement with 65535 parameters.
I know wire format uses unsigned int2 for the number of parameters, so I wanted to test if the driver supports that.

a) My first test was like select ? c1, ? c2, ? c3, ..., ? c65535
Then it failed with "ERROR: target lists can have at most 1664 entries".
I do not think "columns per table" is applicable to select like that

b) Then I tried select ?||?||?||?||....||?
I wanted to verify that the driver sent all the values properly, so I don't want to just ignore them and I concatenated the values.
Unfortunately, it failed with "stack depth limit exceeded. Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depth limit is adequate"

Finally, I settled on select ARRAY[?, ?, ... ?] which worked up to 65535 parameters just fine.
Please, do not suggest me avoid 65535 parameters. What I wanted was just to test that the driver was able to handle 65535 parameters.

Vladimir

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word
Следующее
От: Robert Haas
Дата:
Сообщение: Re: PG15 beta1 sort performance regression due to Generation context change