Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Date
Msg-id 4093668.1612449911@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai <kaigai@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.

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.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Is Recovery actually paused?
Next
From: Tomas Vondra
Date:
Subject: Re: Preserve attstattarget on REINDEX CONCURRENTLY