Yes, the additional bitmap could certainly explain the increase.
Thanks,
Mike
-Original Message-
From: Justin Pryzby [mailto:pry...@telsasoft.com]
Sent: Friday, December 06, 2019 6:29 PM
To: Mike Schanne
Cc: pgsql-performa...@postgresql.org
Subject: Re: unexpected result for wastedbytes
...@emolecules.com]
Sent: Friday, December 06, 2019 1:42 PM
To: Mike Schanne
Cc: pgsql-performa...@postgresql.org
Subject: Legal disclaimers on emails to this group
(I've changed the original subject, "autovacuum locking question", of the
sender's email so as not to hijack that thread.)
Hi all,
This question is somewhat related to my previous question:
https://www.postgresql.org/message-id/0871fcf35ceb4caa8a2204ca9c38e330%40USEPRDEX1.corp.kns.com
I was attempting to measure the benefit of doing a VACUUM FULL on my database.
I was using the query found here:
https://wiki.postg
.
From: Jeff Janes [mailto:jeff.ja...@gmail.com]
Sent: Thursday, December 05, 2019 6:55 PM
To: Mike Schanne
Cc: pgsql-performa...@postgresql.org
Subject: Re: autovacuum locking question
On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne
mailto:mscha...@kns.com>> wrote:
Hi,
I am investigating a perfo
/
Thanks,
Mike
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, December 05, 2019 6:49 PM
To: Mike Schanne
Cc: 'pgsql-performa...@postgresql.org'
Subject: Re: autovacuum locking question
Mike Schanne writes:
> I am investigating a performance p
In this particular case autovacuum_count is 0. n_live_tup is 659,631 and
n_dead_tup is 3,400,347.
We are using the default vacuum parameters.
From: Michael Lewis [mailto:mle...@entrata.com]
Sent: Thursday, December 05, 2019 5:49 PM
To: Mike Schanne
Cc: pgsql-performa...@postgresql.org
Subject
Hi,
I am investigating a performance problem in our application and am seeing
something unexpected in the postgres logs regarding the autovacuum.
2019-12-01 13:05:39.029
UTC,"wb","postgres",6966,"127.0.0.1:53976",5ddbd990.1b36,17099,"INSERT
waiting",2019-11-25 13:39:28 UTC,12/1884256,12615023,L