Re: Patching for increasing the number of columns - Mailing list pgsql-hackers

From Steven Niu
Subject Re: Patching for increasing the number of columns
Date
Msg-id CABBtG=cr2DqAv5JW3b64yKTGW-FZuw97bibML_kDwY+vfMah5Q@mail.gmail.com
Whole thread Raw
In response to Re: Patching for increasing the number of columns  (Mayeul Kauffmann <mayeul.kauffmann@free.fr>)
List pgsql-hackers


Mayeul Kauffmann <mayeul.kauffmann@free.fr> 于2024年12月13日周五 15:11写道:

On 20/08/14 18:17, Tom Lane wrote:
> Hm. I think the without_oid test is not showing that anything is broken;

> The other tests aren't showing any functional issue either AFAICS.
Thanks a lot Tom! That's very helpful.
I have written more details and some basic SQL tests in the wiki of the
application (LimeSurvey) which requires this:

http://manual.limesurvey.org/Instructions_for_increasing_the_maximum_number_of_columns_in_PostgreSQL_on_Linux

I will give update here or on that wiki (where most relevant) should I
find issues while testing.

Cheers,

mayeulk



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



Hi,  Mayeul ,

I tried your solution on PG17.2 and it does works when the columns is less than 2048. 
However, when there are 2048 columns in one table,  you cannot read out the content of table.

postgres=# CREATE TABLE large_table (
    col1 char,
    col2 char,
    col3 char,
    col4 char,
    col5 char,
    ...... 
    col2045 char,
    col2046 char,
    col2047 char,
    col2048 char
);
CREATE TABLE

postgres=# insert into large_table values(3);
INSERT 0 1

postgres=# select col1 from large_table;
col1
------

(1 row)

Yes, there does be a tuple in this table and the result shows you one row is retrieved. But you got nothing. Definitely some limitation still exists somewhere.

Steven

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.
Next
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions