Re: Vacuum and state_change

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: armand pirvu <armand(dot)pirvu(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Vacuum and state_change
Date: 2017-06-09 20:52:35
Message-ID: 263ba109-605e-b786-d2c6-f4089470c024@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 06/09/2017 01:31 PM, armand pirvu wrote:

>>
>> Are these large tables?

> I would say yes
>
> select count(*) from csischema.tf_purchased_badge;
> 9380749
>
> select count(*) from csischema.tf_purchases_person;
> 19902172
>
> select count(*) from csischema.tf_demographic_response_person;
> 80868561
>
> select count(*) from csischema.tf_transaction_item_person;
> 3281084
>
> Interesting enough two completed

So the two 'smaller' tables which would make sense.

>
> relname | seq_scan | seq_tup_read | idx_scan |
> idx_tup_fetch | n_tup_ins | n_tup_upd | n_live_tup | n_dead_tup |
> n_mod_since_analyze | last_vacuum | last_autovacuum |
> autovacuum_count
> ----------------------------+----------+--------------+----------+---------------+-----------+-----------+------------+------------+---------------------+-------------+-------------------------------+------------------
> tf_transaction_item_person | 160 | 0 | 476810 |
> 1946119 | 2526 | 473678 | 3226110 | 0 |
> 116097 | | 2017-06-09 11:15:24.701997-05 | 2
> tf_purchased_badge | 358 | 1551142438 | 2108331 |
> 7020502 | 5498 | 1243746 | 9747336 | 107560 |
> 115888 | | 2017-06-09 15:09:16.624363-05 | 1
>
>
> I did notice though that checkpoints seem a bit too often aka below 5
> min from start to end

You probably should take a look at:

https://www.postgresql.org/docs/9.6/static/wal-configuration.html

and

https://www.postgresql.org/docs/9.6/static/routine-vacuuming.html#AUTOVACUUM

> These tables suffer quite some data changes IIRC but that comes via some
> temp tables which reside in a temp schema and some previous messages
> from the log suggest that it might have ran into ladder locking in
> early stages, aka tmp table locked from vacuum and any further
> processing waiting for it and causing some other waits on those largish
> tables

Did you do a manual VACUUM of the temporary tables?

If not see below.

>
> Considering the temp ones are only for load and yes some processing goes
> in there , I am thinking disabling auto vacuum for the temp tables . Or
> should I disable auto vacuum all together and run say as a bath job on a
> weekend night ?

I don't think temporary tables are the problem as far as autovacuum goes:

https://www.postgresql.org/docs/9.6/static/routine-vacuuming.html#AUTOVACUUM

"Temporary tables cannot be accessed by autovacuum. Therefore,
appropriate vacuum and analyze operations should be performed via
session SQL commands."

>
>> If you are on Postgres 9.6:
>>
>> https://www.postgresql.org/docs/9.6/static/progress-reporting.html
>>
>
> Aside that there are vacuum improvements and such, any other strong
> compelling reason to upgrade to 9.6 ?

That would depend on what version you are on now. If it is out of
support then there would be a reason to upgrade, not necessarily to 9.6
though.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message armand pirvu 2017-06-09 21:01:09 Re: Vacuum and state_change
Previous Message armand pirvu 2017-06-09 20:31:20 Re: Vacuum and state_change