Postgres Pro
Downloads
Home   >   mailing lists

Re: R: Vacuum full: alternatives? - Mailing list pgsql-general

From Melvin Davidson
Subject Re: R: Vacuum full: alternatives?
Date
Msg-id CANu8FiwewCLy5tEtau3AiMNcpYwpibCkvZt_VAV_zfyptALbXQ@mail.gmail.com
Whole thread Raw
In response to Re: R: Vacuum full: alternatives?  (Scott Mead <scottm@openscg.com>)
Responses Re: R: Vacuum full: alternatives?  (Martín Marqués <martin@2ndquadrant.com>)
List pgsql-general
Tree view


On Mon, Jun 20, 2016 at 11:03 AM, Scott Mead <scottm@openscg.com> wrote:


On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer <andreas@a-kretschmer.de> wrote:


Am 20.06.2016 um 11:43 schrieb Job:
Hi Andreas,

I would suggest run only autovacuum, and with time you will see a not
more growing table. There is no need for vacuum full.
So new record, when will be pg_bulkloaded, will replace "marked-free" location?


 exactly, that's the task for vacuum


I believe that free space is only available to UPDATE, not INSERT.

 


Andreas


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
--
Scott Mead
Sr. Architect
OpenSCG


Martin and Vik,

>...Think about a SELECT which has to scan all child tables.

You are really digging for a corner case.
If a scan has to scan all child tables, then
A. it negates the ability to make partitions which are not used
and
B. The SELECT query is poorly crafted.

--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

pgsql-general by date:

Previous
From: Scott Mead
Date:
Subject: Re: R: Vacuum full: alternatives?
Next
From: Guillaume Lelarge
Date:
Subject: Re: R: Vacuum full: alternatives?