Re: Design strategy for table with many attributes

Поиск
Список
Период
Сортировка
От Lok P
Тема Re: Design strategy for table with many attributes
Дата
Msg-id CAKna9Vah53TtUX9qYpDz0hPoAFSLUBqtzriWU=xy8vCWQU+Leg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Design strategy for table with many attributes  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Design strategy for table with many attributes
Список pgsql-general

On Fri, 5 Jul, 2024, 1:44 pm David Rowley, <dgrowleyml@gmail.com> wrote:
On Fri, 5 Jul 2024 at 19:53, Lok P <loknath.73@gmail.com> wrote:
> As David suggested it breaks if a row exceeds the 8k limit I. E a single page size , will that still holds true if we have a column with JSON in it?

You wouldn't be at risk of the same tuple length problem if you
reduced the column count and stored the additional details in JSON.
Each varlena column is either stored in the tuple inline, or toasted
and stored out of line. Out of line values need an 18-byte pointer to
the toasted data. That pointer contributes to the tuple length.


David

Got it. Thank you very much. 

So there would be performance overhead with JSON and we need to validate that carefully, if at all going in that direction. 

However out of curiosity, if the roasted/compressed component or column which is JSON itself goes beyond 8k post compression, will it break then? 

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Design strategy for table with many attributes
Следующее
От: David Rowley
Дата:
Сообщение: Re: Design strategy for table with many attributes