use_adaptive_write_buffer_for_dynamic_subcolumns
use_async_block_ids_cache
use_compact_variant_discriminators_serialization
use_const_adaptive_granularity
index_granularity_bytes n’est pas égal à 0) conserve les
granules à une taille constante en octets, de sorte que leur nombre de lignes varie : pour chaque
bloc écrit, le nombre de lignes par granule correspond à index_granularity_bytes divisé par la
taille moyenne d’une ligne dans ce bloc, avec un maximum de index_granularity. Comme ce nombre diffère
d’un granule à l’autre, le nombre de lignes de chaque granule de la part doit être conservé en
mémoire, à raison de 8 octets par granule, ce qui peut représenter des dizaines de gigaoctets pour les grandes tables.
L’activation de la granularité adaptative constante (ce paramètre) conserve au contraire un nombre constant de lignes par granule,
de sorte que leur taille en octets varie. Ce nombre est calculé une seule fois à partir de la taille moyenne d’une
ligne dans la part en cours d’écriture, et une part stocke cette valeur unique
au lieu d’une valeur par granule. Comme tous les granules contiennent le même nombre de lignes,
il n’est pas nécessaire de stocker un nombre de lignes supplémentaire pour chaque granule.
La quantité de mémoire actuellement consacrée à ces valeurs est indiquée par la
métrique TotalIndexGranularityBytesInMemory dans system.asynchronous_metrics,
et, pour chaque part, dans system.parts.index_granularity_bytes_in_memory.
Le paramètre s’applique uniquement aux parts écrites après sa modification. Utilisez
ALTER TABLE … REWRITE PARTS
pour l’appliquer aux parts existantes. Les parts Compact utilisent toujours une granularité adaptative.