| From: | Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru> |
|---|---|
| To: | Vik Fearing <vik(at)2ndquadrant(dot)fr>, Martín Marqués <martin(at)2ndquadrant(dot)com>, Melvin Davidson <melvin6925(at)gmail(dot)com>, Rakesh Kumar <rakeshkumar464a3(at)gmail(dot)com> |
| Cc: | Job <Job(at)colliniconsulting(dot)it>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: R: Vacuum full: alternatives? |
| Date: | 2016-06-20 14:40:47 |
| Message-ID: | 0ff62839-a697-e5bd-84b1-be2430aa4a26@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 20.06.2016 17:30, Vik Fearing wrote:
> On 20/06/16 16:23, Martín Marqués wrote:
>> El 20/06/16 a las 09:50, Melvin Davidson escribió:
>>>
>>>> but it won't let it grow too (or am I missing something).
>>> Yes, you are missing something. By partioning and {Vacuum Full only the
>>> table with data no longer needed}, the rest of the data remains
>>> available to the users
>>> AND space is reclaimed by the O/S, so it's the best of both worlds.
>> That's not entirely true. Think about a SELECT which has to scan all
>> child tables.
> Or any SELECT on the parent at all. The planner needs to examine the
> CHECK constraints on the children and can't do it if the child is locked
> in ACCESS EXCLUSIVE mode.
+1
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martín Marqués | 2016-06-20 14:42:21 | Re: R: Vacuum full: alternatives? |
| Previous Message | Vik Fearing | 2016-06-20 14:30:50 | Re: R: Vacuum full: alternatives? |