2021年2月4日(木) 23:45 Tom Lane <t...@sss.pgh.pa.us>: > > Amit Langote <amitlangot...@gmail.com> writes: > > On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai <kai...@heterodb.com> wrote: > >> I think that MaxHeapAttributeNumber is a senseless restriction for foreign- > >> tables. How about your opinions? > > > My first reaction to this was a suspicion that the > > MaxHeapAttributeNumber limit would be too ingrained in PostgreSQL's > > architecture to consider this matter lightly, but actually browsing > > the code, that may not really be the case. > > You neglected to search for MaxTupleAttributeNumber... > > I'm quite skeptical of trying to raise this limit significantly. > > In the first place, you'd have to worry about the 2^15 limit on > int16 AttrNumbers --- and keep in mind that that has to be enough > for reasonable-size joins, not only an individual table. If you > join a dozen or so max-width tables, you're already most of the way > to that limit. > free_parsestate() also prevents to use target-list more than MaxTupleAttributeNumber. (But it is reasonable restriction because we cannot guarantee that HeapTupleTableSlot is not used during query execution.)
> In the second place, as noted by the comment you quoted, there are > algorithms in various places that are O(N^2) (or maybe even worse?) > in the number of columns they're dealing with. > Only table creation time, isn't it? If N is not small (probably >100), we can use temporary HTAB to ensure duplicated column-name is not supplied. > In the third place, I've yet to see a use-case that didn't represent > crummy table design. Pushing the table off to a remote server doesn't > make it less crummy design. > I met this limitation to create a foreign-table that try to map Apache Arrow file that contains ~2,500 attributes of scientific observation data. Apache Arrow internally has columnar format, and queries to this data-set references up to 10-15 columns on average. So, it shall make the query execution much more efficient. Thanks, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>
