| From: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
|---|---|
| To: | 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:30:50 |
| Message-ID: | 5767FE1A.3030100@2ndquadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Ignatov | 2016-06-20 14:40:47 | Re: R: Vacuum full: alternatives? |
| Previous Message | Martín Marqués | 2016-06-20 14:23:15 | Re: R: Vacuum full: alternatives? |