Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Дата
Msg-id 4093668.1612449911@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Is Recovery actually paused?
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Preserve attstattarget on REINDEX CONCURRENTLY