diff --git a/docs/kb/file-compression.md b/docs/kb/file-compression.md
index c393bc6c..535ef69d 100644
--- a/docs/kb/file-compression.md
+++ b/docs/kb/file-compression.md
@@ -187,7 +187,7 @@ There are three key aspects of compression algorithms:
    1. **Compression speed**: This measures the time required to compress a file. Compression is typically CPU-intensive, so a high compression speed minimizes CPU usage and associated costs. High compression speed is good. The time to save a column file determines the upper bound of data ingestion. The faster we can save a file, the more a kdb+ system can ingest. In the [kdb+ tick](../architecture/tickq.md) system, the RDB is unavailable for queries during write, meaning that write speed also affects system availability.
    1. **Decompression speed**: This reflects the time taken to restore the original file from the compressed (encrypted) version. High decompression speed means faster queries.
 
-There is no single best compression algorithm that outperforms all others in all aspects. You need to select compression (or avoid compression) based on your priorities:
+**There is no single best compression algorithm that outperforms all others in all aspects.** You need to select compression (or avoid compression) based on your priorities:
 
   - Is achieving the fastest possible query execution more important to you, or do you prefer to minimize storage costs?
   - Does your kdb+ system handle a high volume of incoming data, requiring a reliable intraday write process to manage the data effectively?