160 million is a very low number. I manage production databases which
reach this value in a day easily. As other said, 200 million is the
default threshold for the anti-wraparound vacuums. I wouldn't worry,
specially for template0.
That said, there is nothing preventing you from temporarily changin
On 01/08/18 18:36, Andres Freund wrote:
> It's really annoying to
> get a hard to kill ant-wraparound autovacuum on an insert only table,
> where it's the only thing that'll trigger the autovacuum.
Somebody should do something about that.
--
Vik Fearing +3
On 2018-08-01 12:20:15 -0400, Alvaro Herrera wrote:
> On 2018-Aug-01, Andres Freund wrote:
>
> > On 2018-08-01 12:07:16 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2018-08-01 10:24:24 -0400, Tom Lane wrote:
> > > >> IMO, the action you need to take is enabling autovacuum. We've
On 2018-Aug-01, Andres Freund wrote:
> On 2018-08-01 12:07:16 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2018-08-01 10:24:24 -0400, Tom Lane wrote:
> > >> IMO, the action you need to take is enabling autovacuum. We've
> > >> seen many many people go down the path you are taking, a
On 2018-08-01 12:07:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-01 10:24:24 -0400, Tom Lane wrote:
> >> IMO, the action you need to take is enabling autovacuum. We've
> >> seen many many people go down the path you are taking, and it's
> >> generally led to no good in the end
Andres Freund writes:
> On 2018-08-01 10:24:24 -0400, Tom Lane wrote:
>> IMO, the action you need to take is enabling autovacuum. We've
>> seen many many people go down the path you are taking, and it's
>> generally led to no good in the end. Manual vacuuming tends
>> to miss stuff, and it canno
Hi,
On 2018-08-01 10:24:24 -0400, Tom Lane wrote:
> Rijo Roy writes:
> > Thanks for the advice. Autovacuum is disabled in the environment and I
> > cannot take a call on enabling it back. I can only run manual vacuum on the
> > database as the dev team fears autoanalyze changing the query perfo
On 2 August 2018 at 02:31, Rijo Roy wrote:
> I agree.. But unfortunately it is the business call and we cannot alter it..
> I am planning to convince them by keeping autovacuum_analyze_threshold to a
> high value so that auto analyse will not kick in very often leaving the
> autovacuum to do its j
I agree.. But unfortunately it is the business call and we cannot alter it.. I
am planning to convince them by keeping autovacuum_analyze_threshold to a high
value so that auto analyse will not kick in very often leaving the autovacuum
to do its job.. Please advise.
Thanks, Rijo Roy
Sent from
Rijo Roy writes:
> Thanks for the advice. Autovacuum is disabled in the environment and I cannot
> take a call on enabling it back. I can only run manual vacuum on the database
> as the dev team fears autoanalyze changing the query performance. Do you
> still think we don't need to take any act
Hi Tom,
Thanks for the advice. Autovacuum is disabled in the environment and I cannot
take a call on enabling it back. I can only run manual vacuum on the database
as the dev team fears autoanalyze changing the query performance. Do you still
think we don't need to take any actions.
Thanks, Ri
Rijo Roy writes:
> I am observing a steady increase in age(datfrozenxid) of template0 database
> in my Postgresql 10 running in a RHEL 6.9Currently, it is at 166846989 and I
> am not able to vacuum the same as datallowconn is false. Thought of setting
> it to true and perform a vacuum freeze on
Hello Everyone,
I am observing a steady increase in age(datfrozenxid) of template0 database in
my Postgresql 10 running in a RHEL 6.9Currently, it is at 166846989 and I am
not able to vacuum the same as datallowconn is false. Thought of setting it to
true and perform a vacuum freeze on the same
13 matches
Mail list logo
