Update 60-optimize-table.md

Author: BohuTANG

docs/en/sql-reference/10-sql-commands/00-ddl/01-table/60-optimize-table.md

@@ -47,8 +47,7 @@ Databend creates a unique ID for each database and table for storing the snapsho
 
 ## Table Optimizations
 
-In Databend, it's advisable to aim for an ideal block size of either 100MB (uncompressed) or 1,000,000 rows, with each segment consisting of 1,000 blocks. To maximize table optimization, it's crucial to gain a clear understanding of when and how to apply various optimization techniques, such as [Segment Compaction](#segment-compaction), [Block Compaction](#block-compaction), and [Purging](#purging).
-
+In Databend, it's advisable to aim for an ideal block size of either 100MB (uncompressed) or 1,000,000 rows, with each segment consisting of 1,000 blocks. To maximize table optimization, it's crucial to gain a clear understanding of when and how to apply various optimization techniques, such as [Segment Compaction](#segment-compaction) and [Block Compaction](#block-compaction).
 - When using the COPY INTO or REPLACE INTO command to write data into a table that includes a cluster key, Databend will automatically initiate a re-clustering process, as well as a segment and block compact process.
 
 - Segment & block compactions support distributed execution in cluster environments. You can enable them by setting ENABLE_DISTRIBUTED_COMPACT to 1. This helps enhance data query performance and scalability in cluster environments.
@@ -172,86 +171,3 @@ Compacts the table data by merging small blocks and segments into larger ones.
 ```sql
 OPTIMIZE TABLE my_database.my_table COMPACT LIMIT 50;
 ```
-
-### Purging
-
-Purging permanently removes historical data, including unused snapshots, segments, and blocks, except for the snapshots within the retention period (including the segments and blocks referenced by this snapshot), which will be retained. This can save storage space but may affect the Time Travel feature. Consider purging when:
-
-- The storage cost is a major concern, and you don't require historical data for Time Travel or other purposes.
-- You've compacted your table and want to remove older, unused data.
-
-:::note
-Historical data within the default retention period of 24 hours will not be removed. To adjust the retention period, use the *data_retention_time_in_days* setting.
-:::
-
-**Syntax**
-
-```sql
-OPTIMIZE TABLE <table_name> PURGE 
-  [ BEFORE 
-          (SNAPSHOT => '<SNAPSHOT_ID>') | 
-          (TIMESTAMP => '<TIMESTAMP>'::TIMESTAMP) |
-          (STREAM => <stream_name>)
-  ]
-  [ LIMIT <snapshot_count> ]
-```
-
-| Parameter | Description                                                                                                                                                                          |
-|-----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| BEFORE    | Specifies the condition for purging historical data. It is used with the `SNAPSHOT`, `TIMESTAMP`, or `STREAM` option to define the point in time before which data should be purged. <br/>When a `BEFORE` option is specified, the command purges historical data by first selecting a base snapshot as indicated by the specified option. Subsequently, it removes snapshots generated before this base snapshot. In the case of specifying a stream with `BEFORE STREAM`, the command identifies the nearest snapshot preceding the creation of the stream as the base snapshot. It then proceeds to remove snapshots generated before this nearest snapshot.|
-| LIMIT     | Sets the maximum number of snapshots to be purged. When specified, Databend will select and purge the oldest snapshots, up to the specified count.                                   |
-
-**Examples**
-
-This example demonstrates purging historical data using the `BEFORE STREAM` option.
-
-1. Create a table named `t` with a single column `a`, and insert two rows with values 1 and 2 into the table.
-
-```sql
-CREATE TABLE t(a INT);
-
-INSERT INTO t VALUES(1);
-INSERT INTO t VALUES(2);
-```
-
-2. Create a stream named `s` on the table `t`, and add an additional row with value 3 into the table.
-
-```sql
-CREATE STREAM s ON TABLE t;
-
-INSERT INTO t VALUES(3);
-```
-
-3. Return snapshot IDs and corresponding timestamps for the table `t`.
-
-```sql
-SELECT snapshot_id, timestamp FROM FUSE_SNAPSHOT('default', 't');
-
-┌───────────────────────────────────────────────────────────────┐
-│            snapshot_id           │          timestamp         │
-├──────────────────────────────────┼────────────────────────────┤
-│ 00dd8ca67c1f461987f31a6b3a1c3c84 │ 2024-04-02 18:09:39.157702 │
-│ e448bb2bf488489dae7294b0a8af38d1 │ 2024-04-02 18:09:34.986507 │
-│ 2ac038dd83e741afbae543b170105d63 │ 2024-04-02 18:09:34.966336 │
-└───────────────────────────────────────────────────────────────┘
-
--- Setting data retention time to 0 for demonstration purposes only. Not recommended in production.
-SET data_retention_time_in_days = 0;
-```
-
-4. Purge historical snapshots using the `BEFORE STREAM` option.
-
-```sql
-OPTIMIZE TABLE t PURGE BEFORE (STREAM => s);
-
--- The command selects snapshot ID e448bb2bf488489dae7294b0a8af38d1 as the base, which was generated immediately before the creation of stream 's'.
--- As a result, snapshot ID 2ac038dd83e741afbae543b170105d63, generated before the base, is removed.
-SELECT snapshot_id, timestamp FROM FUSE_SNAPSHOT('default', 't');
-
-┌───────────────────────────────────────────────────────────────┐
-│            snapshot_id           │          timestamp         │
-├──────────────────────────────────┼────────────────────────────┤
-│ 00dd8ca67c1f461987f31a6b3a1c3c84 │ 2024-04-02 18:09:39.157702 │
-│ e448bb2bf488489dae7294b0a8af38d1 │ 2024-04-02 18:09:34.986507 │
-└───────────────────────────────────────────────────────────────┘
-```