| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Baptiste LHOSTE *EXTERN*" <blhoste(at)alaloop(dot)com>, 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: | Re: Autovacuum issues with truncate and create index ... |
| Date: | 2013-01-17 11:30:27 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B0579A96D@ntex2010a.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Baptiste LHOSTE wrote:
> 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 ?
Maybe more of the first table is cached.
Maybe contention on the table or the I/O system in general
varied between the two VACUUMs.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Whitney | 2013-01-17 16:20:17 | Replication monitoring questions |
| Previous Message | Baptiste LHOSTE | 2013-01-17 09:23:39 | Autovacuum issues with truncate and create index ... |