On Fri, Jul 26, 2019 at 9:21 PM PegoraroF10 wrote:
> So, is it better to configure autovacuum properly to these tables or should
> I run vacuum periodically ?
> Obviously I´ll check our script too.
>
My guess would be that either you have disabled autovacuum on such
tables (I don't know if that i
Correct, seems to be something wrong on system tables. Maybe our script is
running something is already there, we will check.
select * from pg_stat_sys_tables where schemaname = 'pg_catalog'
relname n_live_tup n_dead_tup
pg_attrdef 3699 1095
pg_index
pg_stat_all_tables
count count
37158 807
pg_stat_sys_tables
count count
16609 223
pg_stat_user_tables
count count
20549 584
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On Fri, Jul 26, 2019 at 1:15 PM PegoraroF10 wrote:
>
> select count(*), count(*) filter (where last_autovacuum is not null) from
> pg_stat_all_tables
> count count
> 36605 1178
>
What are the results of the same query against pg_stat_sys_tables and
pg_stat_user_tables? That's would help under
On 7/26/19 4:15 AM, PegoraroF10 wrote:
select count(*), count(*) filter (where last_autovacuum is not null) from
pg_stat_all_tables
count count
36605 1178
But what tables should I see if vacuum ran on it ?
I would recommend reading this:
https://www.postgresql.org/docs/11/routine-vacuumin
select count(*), count(*) filter (where last_autovacuum is not null) from
pg_stat_all_tables
count count
36605 1178
But what tables should I see if vacuum ran on it ?
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Nope, that schema and all its entire structure did not exist.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Running that sql:
namesetting
autovacuum on
autovacuum_analyze_scale_factor 0.1
autovacuum_analyze_threshold50
autovacuum_freeze_max_age 2
autovacuum_max_workers 3
autovacuum_multixact_freeze_max_age 4
autovacuum_naptime 60
autovacuum_vacuum_cost_delay
PegoraroF10 schrieb am 26.07.2019 um 00:16:
> statement: create or replace function valoresdfe... 0 mins 1.135 secs
> statement: create or replace function dadosorigem...0 mins 0.055 secs
> statement: CREATE OR REPLACE FUNCTION SONU... 0 mins 0.013 secs
> statement: create or repl
On Fri, Jul 26, 2019 at 1:01 AM PegoraroF10 wrote:
>
> Nope, no one message near those statements.
> I haven´t changed anything on Postgres.conf related with autovacuum.
>
Please take a look and post results of the following query:
select name, setting from pg_settings where name like 'autovacuu
On 7/25/19 4:01 PM, PegoraroF10 wrote:
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
You probably should also look at this system view:
https://www.postgresql.org/docs/11/monitoring-stats.html#PG-STAT-ALL-TABLES-VIEW
to see w
On 7/25/19 4:01 PM, PegoraroF10 wrote:
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
So what are the settings?
--
Adrian Klaver
adrian.kla...@aklaver.com
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On 7/25/19 3:16 PM, PegoraroF10 wrote:
So, what should I tune on autovacuum ?
My script was running strangely. Postgres log shows me the time spent to
create functions. That happens when creating triggers and tables too.
Sometimes it´s too fast and sometimes ...
I didn't realize there is too fa
So, what should I tune on autovacuum ?
My script was running strangely. Postgres log shows me the time spent to
create functions. That happens when creating triggers and tables too.
Sometimes it´s too fast and sometimes ...
statement: create or replace function valoresdfe... 0 mins 1.135 secs
On 7/24/19 11:33 AM, PegoraroF10 wrote:
I did not have vacuumed or reindexed my database for last 30 days and that
was my problem.
Autovacuum should be dealing with this.
Do you have it throttled in some manner?
It works fine if I do a reindex database before adding that new schema.
Well, I´
I did not have vacuumed or reindexed my database for last 30 days and that
was my problem.
It works fine if I do a reindex database before adding that new schema.
Well, I´ll try just reindexing system before adding a new schema to see if
it works.
--
Sent from: https://www.postgresql-archive.
On Tue, Jul 23, 2019 at 1:36 PM Adrian Klaver
wrote:
> On 7/23/19 12:20 PM, PegoraroF10 wrote:
> > We have in a single database 190 identical schemas. Now, when we create
> a new
> > one, with exactly same structure as the previous ones, it takes 20 or 30
> > minutes to finish. Usual time to fini
On 7/23/19 12:20 PM, PegoraroF10 wrote:
We have in a single database 190 identical schemas. Now, when we create a new
one, with exactly same structure as the previous ones, it takes 20 or 30
minutes to finish. Usual time to finish that script was 30 seconds.
Basically, my script creates an entir
We have in a single database 190 identical schemas. Now, when we create a new
one, with exactly same structure as the previous ones, it takes 20 or 30
minutes to finish. Usual time to finish that script was 30 seconds.
Basically, my script creates an entire structure for a new customer:
- Create s
20 matches
Mail list logo
