Re: huge table occupation after updates

["t.dalpozzo@xxxxxxxxx" <t.dalpozzo@xxxxxxxxx>]

Il 12/12/2016 02:42, David G. Johnston ha scritto:

On Saturday, December 10, 2016, Tom DalPozzo <t.dalpozzo@xxxxxxxxx> 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,

Hi David,
 there are also other DB clients which only perform read queries using SQL. It's the reason why I chose postgreSQL over simpler apps. I didn't mention about them so far as those queries are not a concern in terms of performance.

Anyway, regarding the huge dimension of the table,  I think that reason was that autovacuum didn't work as the updates traffic was really high in my test, with no pause. Infact, if I lower it down to 1500updates/sec, then autovacuum works (I checked the log).
So the table size can grow but not for ever as it gets reused.
Thank you very much.

Pupillo