Re: row is too big: size 8168, maximum size 8160

I've been able to solve it reducing the precision of the data inside
the columns to 2 decimals. The original data was stored as integer, I
was putting much more data inside adding precision that wasn't needed
:)

Thank you for your responses :)

2018-07-11 18:17 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Mario de Frutos Dieguez <mariodefrutos(at)gmail(dot)com> writes:
>> Thank you for your quick answer. We have to think if we can rearrange it.
>> The funny thing is that we have the same number of columns for other
>> tables which are the same except for stored geometries and those
>> stores the information without any problem.
>> That's why I thought maybe is a corruption thing or something
>
> No, it's just too many columns. If we suppose that the average width of
> your numeric columns is 12 bytes, then you need 790*12 = 9480 bytes,
> which doesn't fit on an 8K page even without any accounting for row
> header and page header overhead. TOAST can't help by pushing values
> out-of-line, because a TOAST pointer is 18 bytes so it'd actually make
> things worse. (TOAST works well for individual large fields, but not
> at all for this case.)
>
> You can get away with 790 columns if they're 4 or 8 bytes apiece, or if
> many of them are NULL, but evidently these particular numeric values
> average more than that.
>
> In practice, though, there are a lot of other inefficiencies with
> tables that have so many columns. So I counsel looking into arrays
> or some other approach.
>
> regards, tom lane
>