Hi, I'd like to do that! But my DB must be crash proof! Very high reliability is a must. I also use sycn replication. Regards Pupillo
2016-12-10 16:04 GMT+01:00 Rob Sargent <robjsarg...@gmail.com>: > > > On Dec 10, 2016, at 6:25 AM, Tom DalPozzo <t.dalpo...@gmail.com> wrote: > > > > Hi, > > you're right, VACUUM FULL recovered the space, completely. > > So, at this point I'm worried about my needs. > > I cannot issue vacuum full as I read it locks the table. > > In my DB, I (would) need to have a table with one bigint id field+ 10 > bytea fields, 100 bytes long each (more or less, not fixed). > > 5/10000 rows maximum, but let's say 5000. > > As traffic I can suppose 10000 updates per row per day (spread over > groups of hours; each update involving two of those fields, randomly. > > Also rows are chosen randomly (in my test I used a block of 2000 just to > try one possibility). > > So, it's a total of 50 millions updates per day, hence (50millions * 100 > bytes *2 fields updated) 10Gbytes net per day. > > I'm afraid it's not possible, according to my results. > > Reagrds > > Pupillo > > > > Are each of the updates visible to a user or read/analyzed by another > activity? If not you can do most of the update in memory and flush a > snapshot periodically to the database. > >
