RE: Monitoring DB size

Thanks for the suggestion. I think this will not help us to differentiate between live tuples, dead tuples and free space. Best regards, Manuel From: Torsten Förtsch Sent: 15 July 2024 18:59 To: Shenavai, Manuel Cc: pgsql-general@lists.postgresql.org Subject: Re: Monitoring DB size Slightly

RE: Monitoring DB size

: Shenavai, Manuel Cc: pgsql-general@lists.postgresql.org Subject: Re: Monitoring DB size You don't often get email from imtia...@bitnine.net<mailto:imtia...@bitnine.net>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi, You can choose from the

Monitoring DB size

Hi everyone, we currently capture the db size (pg_database_size) which gives the “Disk space used by the database with the specified name”. Is it possible to further split this data how much space is occupied by live tuples, dead tuples and free space? We would like to have something like: DB S

autovacuum_vacuum_cost_delay

Hi everyone, We are doing some tests with different autovacuum settings. Looking at autovacuum_vacuum_cost_delay: https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY Can someone help to understand what a high or low value of this setting really

RE: Configure autovacuum

andom bytearray of x MB) for x minutes. We update up to 60MB per second 4) Postgres Version: 14.12-2 5) We are using default autovacuum-settings Best regards, Manuel -Original Message- From: Adrian Klaver Sent: 04 July 2024 17:43 To: Shenavai, Manuel ; pgsql-general Subject: Re: Confi

RE: Configure autovacuum

-Original Message- From: Adrian Klaver Sent: 14 June 2024 16:32 To: Shenavai, Manuel ; pgsql-general Subject: Re: Configure autovacuum On 6/13/24 23:20, Shenavai, Manuel wrote: > Hi everyone, > > I would like to configure the autovacuum in a way that it runs very > frequently

RE: Autovacuum, dead tuples and bloat

n for 1hour and 1GB data was written." Is there something like this already available in postgres? Best regards, Manuel -Original Message- From: Adrian Klaver Sent: 22 June 2024 23:17 To: Shenavai, Manuel ; Achilleas Mantzios ; pgsql-general@lists.postgresql.org Subject: Re: Autovac

RE: Autovacuum, dead tuples and bloat

use? Best regards, Manuel -Original Message- From: Adrian Klaver Sent: 21 June 2024 22:39 To: Shenavai, Manuel ; Achilleas Mantzios ; pgsql-general@lists.postgresql.org Subject: Re: Autovacuum, dead tuples and bloat On 6/21/24 12:31, Shenavai, Manuel wrote: > Hi, > > Thanks for the s

RE: Autovacuum, dead tuples and bloat

"n_tup_hot_upd": 0, "n_tup_ins": 112635281, "n_tup_upd": 0, "relid": "27240", "relname": "pg_toast_27236", "schemaname": "pg_toast", "seq_scan": 0, "seq_tup_read": 0,

RE: Autovacuum, dead tuples and bloat

"timestamp": "2024-06-19 17:45:02.564 UTC" }, "time": "2024-06-19T17:45:02.568Z" } Best regards, Manuel From: Achilleas Mantzios Sent: 20 June 2024 19:10 To: pgsql-general@lists.postgresql.org Subject: Re: Autovacuum, dead tuples and bloat You do

Autovacuum, dead tuples and bloat

Hi everyone, we can see in our database, that the DB is 200GB of size, with 99% bloat. After vacuum full the DB decreases to 2GB. DB total size: 200GB DB bloat: 198 GB DB non-bloat: 2GB We further see, that during bulk updates (i.e. a long running transaction), the DB is still growing, i.e. the

Configure autovacuum

Hi everyone, I would like to configure the autovacuum in a way that it runs very frequently (i.e. after each update-statement). I tried the following settings on my table: alter table mytable set (autovacuum_vacuum_scale_factor = 0.0); alter table mytable set (autovacuum_vacuum_cost_delay = 0.0

TOAST Table / Dead Tuples / Free Pages

Hi everyone, I created a simple scenario to understand the handling of TOASTs: There is an empty database with a single table and record. The single record gets updated multiple times with 10MB (bytea column). I can see that the table/

autoanalyze / autovacuum vs manually executed "vacuum analyze"

Hi everyone, we created an index on a table to improve the performance for a SQL statement. After executing “vacuum analyze mytable”, the index is used. I know that there is also an autovacuum/autoanalyzer configured. I can see that autovacuum and autoanalyzer ran recently. But the index is sti