| From: | Martín Marqués <martin(at)2ndquadrant(dot)com> |
|---|---|
| To: | 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:23:15 |
| Message-ID: | a3fa3519-7685-0425-50e1-276653896836@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
Your are also adding another layer of complexity to the system.
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2016-06-20 14:30:50 | Re: R: Vacuum full: alternatives? |
| Previous Message | Johan Thomsen | 2016-06-20 14:22:19 | pg_dump from a hot standby replication slave |