Re: [GENERAL] huge table occupation after updates

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [GENERAL] huge table occupation after updates
Дата
Msg-id CAKFQuwY-Vzo_DjA+m1EzXGXkKmffSt3Db+-D=rgYaJJpkqnhgw@mail.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 Saturday, December 10, 2016, Tom DalPozzo <t.dalpozzo@gmail.com> wrote:

​I have one direct DB client (let's name it MIDAPP) only. This client of the DB is a server for up to 10000 final clients.
Any time MIDAPP is going to reply to a client, it must save a "status record with some data" related to that client and only after that, answering /committing the final client.
The next time the same final client will ask something, the same status record will be updated again (with a different content).

Why do you want to pay for concurrency control when you don't seem to need it?  While PostgreSQL likely can do what you need I suspect there are applications out there that can solve this specific problem better.  Even something as simple as a flat file, one per "final client", written atomically and fsynced after each write/rename.

David J,

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

Предыдущее
От: Patrick B
Дата:
Сообщение: Re: [GENERAL] WAL history files - Pgsql 9.2
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [GENERAL] Re: [ADMIN] Would like to below scenario is possiblefor getting page/block corruption