Re: R: Vacuum full: alternatives?
От | Melvin Davidson |
---|---|
Тема | Re: R: Vacuum full: alternatives? |
Дата | |
Msg-id | CANu8FiwewCLy5tEtau3AiMNcpYwpibCkvZt_VAV_zfyptALbXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: R: Vacuum full: alternatives? (Scott Mead <scottm@openscg.com>) |
Ответы |
Re: R: Vacuum full: alternatives?
|
Список | pgsql-general |
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 notSo new record, when will be pg_bulkloaded, will replace "marked-free" location?
more growing table. There is no need for vacuum full.
exactly, that's the task for vacuumI 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--
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.
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.

В списке pgsql-general по дате отправления: