On Mon, Nov 21, 2016 at 11:34 AM, dhaval jaiswal wrote:
> Due to business impact auto vacuum is off.
You have now discovered some of the the negative business impact of
turning it off. If you leave it off, much worse is likely to
follow.
--
Kevin Grittner
EDB:
dhaval jaiswal wrote:
> Adding to above. Below are the outputs.
I just meant that you need to ANALYZE all these system catalogs so that
autovacuum can pick up vacuuming them to remove dead tuples. Do not
leave autovacuum turned off anymore.
--
Álvaro Herrera
r.com>; David G. Johnston
<david.g.johns...@gmail.com>; pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_class (system) table increasing size.
I did check and found it was the bloated size of pg_class which was slowing
down the performance.
It got fixed by adding in routine maintenan
n Grittner; Alvaro Herrera
Cc: Adrian Klaver; David G. Johnston; pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_class (system) table increasing size.
I did check and found it was the bloated size of pg_class which was slowing
down the performance.
It got fixed by adding in routine mainte
On Mon, Nov 21, 2016 at 10:34 AM, dhaval jaiswal
wrote:
> Due to business impact auto vacuum is off.
>
You won't get much sympathy if you turn this feature off. The question
you should be pondering is how to properly configure it for your
environment.
pg_class gets
dhaval jaiswal wrote:
> I did check and found it was the bloated size of pg_class which was slowing
> down the performance.
>
> It got fixed by adding in routine maintenance task. Things are fine now.
Good to know.
> However, I want to know how come pg_class (system table) get
>
G. Johnston;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_class (system) table increasing size.
On Thu, Nov 17, 2016 at 3:16 PM, Alvaro Herrera
<alvhe...@2ndquadrant.com> wrote:
> Looks like you lost the stat data awhile ago (probably due to a server
> crash, or pg_stats_r
On Thu, Nov 17, 2016 at 3:16 PM, Alvaro Herrera
wrote:
> Looks like you lost the stat data awhile ago (probably due to a server
> crash, or pg_stats_reset()) and it never got updated. I suggest doing
> "ANALZYE pg_class" to create initial stats; that might prompt
dhaval jaiswal wrote:
> select * from pg_stat_sys_tables where relname = 'pg_class';
>
> -[ RECORD 1 ]---+---
> relid | 1259
> schemaname | pg_catalog
> relname | pg_class
> seq_scan| 1838
> seq_tup_read| 3177416
> idx_scan
ize of pg_class table is of 5 GB. However, the existing row is
> only 2380 only. It's got fragmented.
>
> --
> *From:* Adrian Klaver <adrian.kla...@aklaver.com>
> *Sent:* Thursday, November 17, 2016 8:29 PM
> *To:* dhaval jaiswal; David G. Johnston
:29 PM
To: dhaval jaiswal; David G. Johnston
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_class (system) table increasing size.
On 11/16/2016 07:08 PM, dhaval jaiswal wrote:
>
>>> Because you are creating (specific) objects.
>
> I have gone through the link and how
On 11/16/2016 07:08 PM, dhaval jaiswal wrote:
Because you are creating (specific) objects.
I have gone through the link and how would i figure out which
specific object is causing this. Can you please elaborate more here.
We do not have the much temporary table usage.
Since the size is
*Sent:* Thursday, November 17, 2016 8:13 AM
*To:* dhaval jaiswal
*Cc:* pgsql-general@postgresql.org
*Subject:* Re: [GENERAL] pg_class (system) table increasing size.
On Wed, Nov 16, 2016 at 7:30 PM, dhaval jaiswal <dhava...@hotmail.com
<mailto:dhava...@hotmail.com>>wrote:
quires maintenance as
well for the pg_class.
It seems its affecting performance.
From: David G. Johnston <david.g.johns...@gmail.com>
Sent: Thursday, November 17, 2016 8:13 AM
To: dhaval jaiswal
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_c
On Wed, Nov 16, 2016 at 7:30 PM, dhaval jaiswal
wrote:
> PostgreSQL 9.4.0
>
Are generalizing here or are you really running 2+ year old patch version?
> Why pg_class table is getting bigger in size.
>
Because you are creating (specific) objects.
See:
15 matches
Mail list logo