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
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
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 spa
On 2023-07-22 16:37:39 -0400, Gus Spier wrote:
> Isn’t this a perfect opportunity to use the TRUNCATE command to
> quickly remove the data? And follow up by deleting the now empty
> tables?
What's the advantage of first truncating and then deleting a table over
just deleting it?
hp
--
Isn’t this a perfect opportunity to use the TRUNCATE command to quickly remove the data? And follow up by deleting the now empty tables?Regards,GusSent from my iPhoneOn Jul 19, 2023, at 7:33 PM, Rob Sargent wrote:
On 7/19/23 17:15, David Rowley wrote:
On Wed, 19
On 7/19/23 17:15, David Rowley wrote:
On Wed, 19 Jul 2023 at 07:41, Rob Sargent wrote:
You might consider deleting portions of the table in separate (consecutive)
batches (maybe 5% per delete). And then truncate table is not logged so that
might be an alternative.
Can you explain why this w
On Wed, 19 Jul 2023 at 07:41, Rob Sargent wrote:
> You might consider deleting portions of the table in separate (consecutive)
> batches (maybe 5% per delete). And then truncate table is not logged so that
> might be an alternative.
Can you explain why this would be a useful thing to do?
It s
On Tue, 2023-07-18 at 13:58 -0400, Devin Ivy wrote:
> I'm hoping to ensure I understand the implications of dropping a large table
> and
> the space being reclaimed by the database and/or OS. We're using pg v14.
>
> This table is quite large with a primary key and one additional index—all
> toge
On 7/18/23 11:58, Devin Ivy wrote:
Hi all,
I'm hoping to ensure I understand the implications of dropping a large
table and the space being reclaimed by the database and/or OS. We're
using pg v14.
This table is quite large with a primary key and one additional
index—all together these are o
Hi all,
I'm hoping to ensure I understand the implications of dropping a large
table and the space being reclaimed by the database and/or OS. We're using
pg v14.
This table is quite large with a primary key and one additional index—all
together these are on the order of 1TB. The primary key and
10 matches
Mail list logo
