Re: Effects of dropping a large table
От | Ron |
---|---|
Тема | Re: Effects of dropping a large table |
Дата | |
Msg-id | f1815a29-4ef4-bb25-0c20-d3973bf7bb2b@gmail.com обсуждение исходный текст |
Ответ на | Re: Effects of dropping a large table ("Peter J. Holzer" <hjp-pgsql@hjp.at>) |
Список | 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.
В списке pgsql-general по дате отправления: