Re: Autovacuum stuck for hours, blocking queries

From: Hannes Erven <hannes(at)erven(dot)at>
To: pgsql-general(at)postgresql(dot)org
Cc: Tim(dot)Bellis(at)metaswitch(dot)com
Subject: Re: Autovacuum stuck for hours, blocking queries
Date: 2017-02-17 11:46:34
Message-ID: 0bc5ca8e-c346-eab1-2492-545d27a05e10@erven.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tim,

Am 2017-02-15 um 18:30 schrieb Tim Bellis:
> I have a postgres 9.3.4 database table which (intermittently but reliably)
> gets into a state where queries get blocked indefinitely
> [..]
> Notes:
> - This database table is used for about 6 million row writes per day,
> all of which are then deleted at the end of the day.

If you are dumping the contents of the table anyways, why not use
TRUNCATE instead of DELETE? It unlinks and recreates the table data
files, requiring nearly zero IO and analyzing.
Or even drop, and recreate the table with the correct new structure so
you do not even need to ALTER TABLE ?

I'm a bit skeptical of these suggestions since very competent people
have already answered your post and did not come up with this... ;-) the
only drawback I'm aware of is that TRUNCATE will immediatly free disk
space on the OS level, so the table's space will not be "blocked". But
probably the VACUUM you are currently performing will also eventually
release the unused disk space, so this may or may not match the current
behaviour.

Best regards,

-hannes

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gabriel Ortiz Lour 2017-02-17 13:06:36 Streaming Replication Without Downtime
Previous Message Alexander Shchapov 2017-02-17 09:36:19 Re: Load multiple CSV file in Postgres using COPY