mdbx: дополнение ChangeLog.

ChangeLog.md

@@ -4,6 +4,19 @@ ChangeLog
 English version [by liar Google](https://libmdbx-dqdkfa-ru.translate.goog/md__change_log.html?_x_tr_sl=ru&_x_tr_tl=en)
 and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx.dqdkfa.ru/md__change_log.html).
 
+## v0.14.1 в активной разработке без конкретизации даты выпуска
+
+Первый выпуск в новом кусте/линейке версий с добавлением функционала, расширением API и внутренними переработками.
+
+Изменение поведения:
+
+ - Теперь при вставке данных в dupsort-таблицу CoW копирование целевых страниц выполняется после провеки отсутствия добавляемого значения среди уже присутствующих multi-значений (aka дубликатов).
+   В результате вставка уже присутствующих "дубликатов" не приводит к каким-либо изменениям в БД и принципиально увеличивает производительность в таких сценариях.
+   В текущем понимании, добавленная проверка не приводит к заметному увеличению накладных расходов и, как следствие, не приводит к снижению производительности в сценариях с обычным/регулярным обновлением и/или вставкой даннaых.
+
+
+--------------------------------------------------------------------------------
+
 
 ## v0.14.0 от 2023-03-13
 
@@ -16,14 +29,18 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
 Будет реализовано в 0.14.1.
 
 2. Явная дефрагментация БД. В API будет добавлена функция с двумя парами параметров:
- - минимальный (требуемый) объем дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
+ - минимальный (требуемый) объём дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
- - максимальный (ограничивающий) объем дефрагментации и максимальной время, которое допустимо потратить.
+ - максимальный (ограничивающий) объём дефрагментации и максимальной время, которое допустимо потратить.
 
-Упрощенно, алгоритмически явная дефрагментация сводиться к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
+Упрощенно, алгоритмически явная дефрагментация сводится к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
+В результате, после фиксации дефрагментирующей транзакции оригиналы скопированных страниц становяться не-используемыми, а размер БД может быть уменьшен за счет отсечения ни-используемых страниц в конце используемого пространства.
 Будет реализовано в 0.14.2.
 
 3. Нелинейная переработка GC, без остановки переработки мусора на старом MVCC-снимке используемом долгой транзакцией чтения.
 
+После реализации запланированного, любая длительная читающая транзакция по-прежнему будет удерживать от переработки используемый/читаемый MVCC-снимок данных (все образующие его страницы БД), но позволит перерабатывать все неиспользуемые MVCC-снимки, как до читаемого, так и после.
+Это позволит устранить [один из основных архитектурных недостатков](https://libmdbx.dqdkfa.ru/intro.html#long-lived-read) унаследованных от LMDB и связанных с ростом размера БД пропорционально объёму производимых изменений данных на фоне долго работающей транзакции чтения.
+
 Будет реализовано предположительно в 0.14.3, 0.14.4 или даже в 0.15.x.
 Перенос в 0.15.x оправдан возможностью переноса функционала дефрагментации в stable-ветку, но посмотри как пойдут дела.