We have extended the capabilities of FDW by extending and modifying the FdwRoutine structure in order to introduce features and calls that were not required before the introduction of MOT. For example, support for The following new features was added – Add Index, Drop Index/Table, Truncate, Vacuum and Table/Index Memory Statistics. A significant emphasis was put on integration with openGauss logging, replication and checkpointing mechanisms in order to provide consistency for cross-table transactions through failures. In this case, the MOT itself sometimes initiates calls to openGauss functionality through the FDW layer.
diff --git a/content/en/docs/Developerguide/figures/low-latency-(90th-)-performance-benchmarks.png b/content/en/docs/Developerguide/figures/low-latency-90th-performance-benchmarks.png
similarity index 100%
rename from content/en/docs/Developerguide/figures/low-latency-(90th-)-performance-benchmarks.png
rename to content/en/docs/Developerguide/figures/low-latency-90th-performance-benchmarks.png
diff --git a/content/en/docs/Developerguide/figures/low-latency-(90th-transaction-average)-performance-benchmarks.png b/content/en/docs/Developerguide/figures/low-latency-90th-transaction-average-performance-benchmarks.png
similarity index 100%
rename from content/en/docs/Developerguide/figures/low-latency-(90th-transaction-average)-performance-benchmarks.png
rename to content/en/docs/Developerguide/figures/low-latency-90th-transaction-average-performance-benchmarks.png
diff --git a/content/en/docs/Developerguide/mot-concepts.md b/content/en/docs/Developerguide/mot-concepts.md
deleted file mode 100644
index c6562b6ea..000000000
--- a/content/en/docs/Developerguide/mot-concepts.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Mot Concepts
The structure of an MOT table T that has three rows and two indexes is depicted in the figure above. The rectangles represent data rows, and the indexes point to sentinels \(the elliptic shapes\) which point to the rows. The sentinels are inserted into unique indexes with a key and into non-unique indexes with a key + a suffix. The sentinels facilitate maintenance operations so that the rows can be replaced without touching the index data structure. In addition, there are various flags and a reference count embedded in the sentinel in order to facilitate optimistic inserts.
diff --git a/content/en/docs/Developerguide/mot-isolation-levels.md b/content/en/docs/Developerguide/mot-isolation-levels.md
index cfdb0dd39..482f58e6e 100644
--- a/content/en/docs/Developerguide/mot-isolation-levels.md
+++ b/content/en/docs/Developerguide/mot-isolation-levels.md
@@ -5,107 +5,108 @@ Even though MOT is fully ACID-compliant \(as described in the section\), not all
**Table 1** Isolation Levels
The READ COMMITTED isolation level that guarantees that any data that is read was already committed when it was read. It simply restricts the reader from seeing any intermediate, uncommitted or dirty reads. Data is free to be changed after it has been read so that READ COMMITTED does not guarantee that if the transaction re-issues the read, that the same data will be found.
-The SNAPSHOT isolation level makes the same guarantees as SERIALIZABLE, except that concurrent transactions can modify the data. Instead, it forces every reader to see its own version of the world (its own snapshot). This makes it very easy to program, plus it is very scalable, because it does not block concurrent updates. However, in many implementations this isolation level requires higher server resources.
-REPEATABLE READ is a higher isolation level that (in addition to the guarantees of the READ COMMITTED isolation level) guarantees that any data that is read cannot change. If a transaction reads the same data again, it will find the same previously read data in place, unchanged and available to be read.
-Because of the optimistic model, concurrent transactions are not prevented from updating rows read by this transaction. Instead, at commit time this transaction validates that the REPEATABLE READ isolation level has not been violated. If it has, this transaction is rolled back and must be retried.
-Serializable isolation makes an even stronger guarantee. In addition to everything that the REPEATABLE READ isolation level guarantees, it also guarantees that no new data can be seen by a subsequent read.
-It is named SERIALIZABLE because the isolation is so strict that it is almost a bit like having the transactions run in series rather than concurrently.
-
**Summary**
@@ -47,41 +47,42 @@ According to your configuration, one of the following types of logging is implem
The downside of the **Synchronous Redo Logging** option is that it is the slowest logging mechanism of the three options. This is because a client application must wait until all data is written to disk and because of the frequent disk writes \(which typically slow down the database\).
-- **Group Synchronous Redo Logging**
+- **Group Synchronous Redo Logging**
- The **Group Synchronous Redo Logging** option is very similar to the **Synchronous Redo Logging** option, because it also ensures total durability with absolutely no data loss and total synchronization of the client application and the WAL \(Redo Log\) entries. The difference is that the **Group Synchronous Redo Logging** option writes _groups of transaction _redo entries to the WAL Redo Log on the disk at the same time, instead of writing each and every transaction as it is committed. Using Group Synchronous Redo Logging reduces the amount of disk I/Os and thus improves performance, especially when running a heavy workload.
+ The **Group Synchronous Redo Logging** option is very similar to the **Synchronous Redo Logging** option, because it also ensures total durability with absolutely no data loss and total synchronization of the client application and the WAL \(Redo Log\) entries. The difference is that the **Group Synchronous Redo Logging** option writes _groups of transaction _redo entries to the WAL Redo Log on the disk at the same time, instead of writing each and every transaction as it is committed. Using Group Synchronous Redo Logging reduces the amount of disk I/Os and thus improves performance, especially when running a heavy workload.
- The MOT engine performs synchronous Group Commit logging with Non-Uniform Memory Access \(NUMA\)-awareness optimization by automatically grouping transactions according to the NUMA socket of the core on which the transaction is running.
+ The MOT engine performs synchronous Group Commit logging with Non-Uniform Memory Access \(NUMA\)-awareness optimization by automatically grouping transactions according to the NUMA socket of the core on which the transaction is running.
- You may refer to the [NUMA Awareness Allocation and Affinity](numa-awareness-allocation-and-affinity.md) section for more information about NUMA-aware memory access.
+ You may refer to the [NUMA Awareness Allocation and Affinity](numa-awareness-allocation-and-affinity.md) section for more information about NUMA-aware memory access.
- When a transaction commits, a group of entries are recorded in the WAL Redo Log, as follows –
+ When a transaction commits, a group of entries are recorded in the WAL Redo Log, as follows –
- 1. While a transaction is in progress, it is stored in the memory. The MOT engine groups transactions in buckets according to the NUMA socket of the core on which the transaction is running. This means that all the transactions running on the same socket are grouped together and that multiple groups will be filling in parallel according to the core on which the transaction is running.
+ 1. While a transaction is in progress, it is stored in the memory. The MOT engine groups transactions in buckets according to the NUMA socket of the core on which the transaction is running. This means that all the transactions running on the same socket are grouped together and that multiple groups will be filling in parallel according to the core on which the transaction is running.
- Writing transactions to the WAL is more efficient in this manner because all the buffers from the same socket are written to disk together.
+ Writing transactions to the WAL is more efficient in this manner because all the buffers from the same socket are written to disk together.
- > **NOTE:**
- >- Each thread runs on a single core/CPU which belongs to a single socket and each thread only writes to the socket of the core on which it is running.
+ > **NOTE:**
+ >
+ >- Each thread runs on a single core/CPU which belongs to a single socket and each thread only writes to the socket of the core on which it is running.
- 2. After a transaction finishes and the client application sends a Commit command, the transaction redo log entries are serialized together with other transactions that belong to the same group.
- 3. After the configured criteria are fulfilled for a specific group of transactions \(quantity of committed transactions or timeout period as describes in the [REDO LOG \(MOT\)](mot-configuration-settings.md#section361563811235)section\), the transactions in this group are written to the WAL on the disk. This means that while these log entries are being written to the log, the client applications that issued the commit are waiting for a response.
- 4. As soon as all the transaction buffers in the NUMA-aware group have been written to the log, all the transactions in the group are performing the necessary changes to the memory store and the clients are notified that these transactions are complete.
+ 2. After a transaction finishes and the client application sends a Commit command, the transaction redo log entries are serialized together with other transactions that belong to the same group.
+ 3. After the configured criteria are fulfilled for a specific group of transactions \(quantity of committed transactions or timeout period as describes in the [REDO LOG \(MOT\)](mot-configuration-settings.md#section361563811235)section\), the transactions in this group are written to the WAL on the disk. This means that while these log entries are being written to the log, the client applications that issued the commit are waiting for a response.
+ 4. As soon as all the transaction buffers in the NUMA-aware group have been written to the log, all the transactions in the group are performing the necessary changes to the memory store and the clients are notified that these transactions are complete.
- **Technical Description**
+ **Technical Description**
- The four colors represent 4 NUMA nodes. Thus each NUMA node has its own memory log enabling a group commit of multiple connections.
+ The four colors represent 4 NUMA nodes. Thus each NUMA node has its own memory log enabling a group commit of multiple connections.
- **Figure 2** Group Commit – with NUMA-awareness
- **Summary**
+ **Summary**
- The **Group Synchronous Redo Logging** option is a an extremely safe and strict logging option because it ensures total synchronization of the client application and the WAL Redo log entries; thus ensuring total durability and consistency with absolutely no data loss. This logging option prevents the situation where a client application might mark a transaction as successful, when it has not yet been persisted to disk.
+ The **Group Synchronous Redo Logging** option is a an extremely safe and strict logging option because it ensures total synchronization of the client application and the WAL Redo log entries; thus ensuring total durability and consistency with absolutely no data loss. This logging option prevents the situation where a client application might mark a transaction as successful, when it has not yet been persisted to disk.
- On one hand this option has fewer disk writes than the **Synchronous Redo Logging** option, which may mean that it is faster. The downside is that transactions are locked for longer, meaning that they are locked until after all the transactions in the same NUMA memory have been written to the WAL Redo Log on the disk.
+ On one hand this option has fewer disk writes than the **Synchronous Redo Logging** option, which may mean that it is faster. The downside is that transactions are locked for longer, meaning that they are locked until after all the transactions in the same NUMA memory have been written to the WAL Redo Log on the disk.
- The benefits of using this option depend on the type of transactional workload. For example, this option benefits systems that have many transactions \(and less so for systems that have few transactions, because there are few disk writes anyway\).
+ The benefits of using this option depend on the type of transactional workload. For example, this option benefits systems that have many transactions \(and less so for systems that have few transactions, because there are few disk writes anyway\).
- **Asynchronous Redo Logging**
@@ -98,7 +99,7 @@ According to your configuration, one of the following types of logging is implem
Upon transaction commit, the transaction buffer is moved \(pointer assignment – not a data copy\) to a centralized buffer and a new transaction buffer is allocated for the transaction. The transaction is released as soon as its buffer is moved to the centralized buffer and the transaction thread is not blocked. The actual write to the log uses the Postgres walwriter thread. When the walwriter timer elapses, it first calls the AsynchronousRedoLogHandler \(via registered callback\) to write its buffers and then continues with its logic and flushes the data to the XLOG.
**Figure 3** Asynchronous Logging
**Summary**
@@ -111,7 +112,7 @@ According to your configuration, one of the following types of logging is implem
The following describes the design details of each persistence-related component in the In-Memory Engine Module.
**Figure 4** Three Logging Options
The RedoLog component is used by both by backend threads that use the In-Memory Engine and by the WAL writer in order to persist their data. Checkpoints are performed using the Checkpoint Manager, which is triggered by the Postgres checkpointer.
@@ -126,7 +127,7 @@ According to your configuration, one of the following types of logging is implem
In the In-Memory Engine, the transaction log records are stored in a transaction buffer which is part of the transaction object \(TXN\). The transaction buffer is logged during the calls to addToLog\(\) – if the buffer exceeds a threshold it is then flushed and reused. When a transaction commits and passes the validation phase \(OCC SILO\[[Comparison – Disk vs. MOT](comparison-disk-vs-mot.md)\] validation\) or aborts for some reason, the appropriate message is saved in the log as well in order to make it possible to determine the transaction's state during a recovery.
**Figure 5** Per-transaction Logging