Re: [GENERAL] huge table occupation after updates

Поиск
Список
Период
Сортировка
От Tom DalPozzo
Тема Re: [GENERAL] huge table occupation after updates
Дата
Msg-id CAK77FCQ8kfgLCGn9eCvf7HArGQzMkMu6zEB+k-4skroSwA+BUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] huge table occupation after updates  (Rob Sargent <robjsargent@gmail.com>)
Ответы Re: [GENERAL] huge table occupation after updates  (Rob Sargent <robjsargent@gmail.com>)
Re: [GENERAL] huge table occupation after updates  (Francisco Olarte <folarte@peoplecall.com>)
Список pgsql-general
2016-12-10 16:36 GMT+01:00 Rob Sargent <robjsargent@gmail.com>:

> On Dec 10, 2016, at 7:27 AM, Tom DalPozzo <t.dalpozzo@gmail.com> wrote:
>
> 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
>
>
>
>
> 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.
>
>

This list discourages top posting. You’re asked to place your reply at the bottom

You haven’t laid out you’re application architecture (how many clients, who is reading who is writing, etc). Caching doesn’t mean your database is any less crash proof.  At that rate of activity, depending on architecture, you could lose updates in all sorts of crash scenarios.

​As for crash proof, I meant that once my client app is told that her update request was committed, it mustn't get lost (hdd failure apart of course). And I can't wait to flush the cache before telling to the app :"committed".
​I can replicate also the cache on the standby PC of course. ​ 
Regards
Pupillo



 

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

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