Re: [GENERAL] huge table occupation after updates

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: [GENERAL] huge table occupation after updates
Дата
Msg-id 124F9DE5-EE82-4309-BCE7-389FD653DEC1@gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] huge table occupation after updates  (Tom DalPozzo <t.dalpozzo@gmail.com>)
Ответы Re: [GENERAL] huge table occupation after updates
Список pgsql-general
> On Dec 10, 2016, at 6:25 AM, Tom DalPozzo <t.dalpozzo@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
thosefields, 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
inmemory and flush a snapshot periodically to the database. 



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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: [GENERAL] SELECT slow immediately after many update ordelete+insert, except using WHERE .. IN
Следующее
От: Tom DalPozzo
Дата:
Сообщение: Re: [GENERAL] huge table occupation after updates