From: | pabloa98 <pabloa98(at)gmail(dot)com> |
---|---|
To: | Andrew Kerber <andrew(dot)kerber(at)gmail(dot)com> |
Cc: | Michael Lewis <mlewis(at)entrata(dot)com>, Julie Nishimura <juliezain(at)hotmail(dot)com>, Ron <ronljohnsonjr(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: drop database |
Date: | 2019-10-17 22:23:35 |
Message-ID: | CAEjudX4Ybp1=jENVAOKMO2xLukCQkFFG1p0nex-dX5wk417WBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Perhaps you want to TRUNCATE TABLEs. That will mitigate any I/O impact
On Thu, Oct 17, 2019 at 3:13 PM Andrew Kerber <andrew(dot)kerber(at)gmail(dot)com>
wrote:
> If you are decommissioning the database, why not just rm -rf the whole
> system?
>
> On Thu, Oct 17, 2019 at 4:31 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:
>
>> Your plan to loop over tables and truncate them seems great if you are
>> worried. It seems simple to verify that space is being freed as you go, and
>> also easy to change tactics if the need arises.
>>
>>>
>
> --
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'
>
From | Date | Subject | |
---|---|---|---|
Next Message | Олег Самойлов | 2019-10-17 23:31:12 | stable for each row before insert trigger |
Previous Message | Andrew Kerber | 2019-10-17 22:12:57 | Re: drop database |