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@xxxxxxxxxxxxx>: > Mario de Frutos Dieguez <mariodefrutos@xxxxxxxxx> 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 >
