Yes, the additional bitmap could certainly explain the increase.
Thanks,
Mike
-Original Message-
From: Justin Pryzby [mailto:[email protected]]
Sent: Friday, December 06, 2019 6:29 PM
To: Mike Schanne
Cc: [email protected]
Subject: Re: unexpected result for wastedbytes
[email protected]]
Sent: Friday, December 06, 2019 1:42 PM
To: Mike Schanne
Cc: [email protected]
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:[email protected]]
Sent: Thursday, December 05, 2019 6:55 PM
To: Mike Schanne
Cc: [email protected]
Subject: Re: autovacuum locking question
On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne
mailto:[email protected]>> wrote:
Hi,
I am investigating a perfo
/
Thanks,
Mike
-Original Message-
From: Tom Lane [mailto:[email protected]]
Sent: Thursday, December 05, 2019 6:49 PM
To: Mike Schanne
Cc: '[email protected]'
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:[email protected]]
Sent: Thursday, December 05, 2019 5:49 PM
To: Mike Schanne
Cc: [email protected]
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
