From: | Baptiste LHOSTE <blhoste(at)alaloop(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)mail(dot)com> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>, Sylvain CAILLET <scaillet(at)alaloop(dot)com> |
Subject: | Autovacuum issues with truncate and create index ... |
Date: | 2013-01-17 09:23:39 |
Message-ID: | 771E373C48A2FC4381D0A96D112154F3E7951A@DB3PRD0610MB356.eurprd06.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi,
We are still trying to fix our issue and we found following logs :
2013-01-17 09:55:01 CET LOG: automatic vacuum of table "flows.public.agg_t1213_incoming_a6_dst_port_and_proto_f5": index scans: 1
pages: 0 removed, 136547 remain
tuples: 0 removed, 4044679 remain
system usage: CPU 3.21s/5.21u sec elapsed 2005.15 sec
2013-01-17 10:12:50 CET LOG: automatic vacuum of table "flows.public.agg_t1214_outgoing_a1_src_net_f5": index scans: 1
pages: 59886 removed, 37828 remain
tuples: 1645338 removed, 3750874 remain
system usage: CPU 3.01s/4.08u sec elapsed 1015.75 sec
How is it possible that first task took twice the time of the second without any tuples to remove ?
Baptiste
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2013-01-17 11:30:27 | Re: Autovacuum issues with truncate and create index ... |
Previous Message | Phil Monroe | 2013-01-15 19:54:49 | Re: Postgres WAL Recovery Fails... And Then Works... |