Quick question: let’s say I’m dynamically creating tables through ILP. Consider also using default configs, meaning that Symbols are going to be created with 256 capacity. What happens internally if/when unique symbol count goes above 256? I have a symbol here that is far beyond 256 count, but I cant see any bottleneck.

Hi Gabriel, Symbol column capacity is the number of persistent hash table buckets we use internally to store (and look up) symbol integer codes. In your case each bucket holds 4560 / 256 ~= 18 symbol values, so that's why you don't see a significant performance impact. If your column would have a few million distinct values, the impact would be much more significant.

Thanks @Andrey Pechkurov. I would notice that impact on reads or on ingestion too?

Both reads and ingestion, but if you also have CACHE attribute set (that's default setting) on the symbol column, the on-heap cache will make thing less dramatic.

Got it. Just a last one: this parameter can be altered after table creation?

Yes, but you'd have to create a new column, copy the old one there and then swap the old one with the new one. Here are the steps (the example considers STRING -> SYMBOL, but SYMBOL -> SYMBOL with a different capacity requires the same process): https://questdb.io/docs/troubleshooting/faq/#how-do-i-convert-a-string-column-to-a-symbol-or-vice-versa

Nice, thanks! This can also be used to create Index with a capacity different than default, right? Because as of now, we can’t set index capacity with

ALTER TABLE COLUMN ADD INDEX

Index capacity is a totally different beast as symbol indexes are organized differently from the symbol tables. We don't recommend changing the value for index capacity to a non-default one.

Okay, so I’ll just tune symbol capacity.