From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Effects of dropping a large table |
Date: | 2023-07-23 20:05:30 |
Message-ID: | f1815a29-4ef4-bb25-0c20-d3973bf7bb2b@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/23/23 05:27, Peter J. Holzer wrote:
> On 2023-07-23 06:09:03 -0400, Gus Spier wrote:
>> Ah! Truncating a table does not entail all of WAL processes. From the
>> documentation, "TRUNCATE quickly removes all rows from a set of tables. It has
>> the same effect as an unqualified DELETE on each table, but since it does not
>> actually scan the tables it is faster. Furthermore, it reclaims disk space
>> immediately, rather than requiring a subsequent VACUUM operation. This is most
>> useful on large tables." https://www.postgresql.org/docs/14/sql-truncate.html
> I assumed that by "deleting the now empty table" you meant DROPing it.
> (Performing a «DELETE FROM t» just after a «TRUNCATE t» would obviously
> be pointless).
>
> So let me rephrase the question:
>
> What's the advantage of
>
> TRUNCATE t
> DROP t
>
> over just
>
> DROP t
Catalog or serialization locking? (I don't know; just asking.)
--
Born in Arizona, moved to Babylonia.
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-07-24 00:57:05 | pageinspect bt_page_items doc |
Previous Message | Peter J. Holzer | 2023-07-23 10:27:33 | Re: Effects of dropping a large table |