- When you attempt to store a string based MLMD property backed by MySQL,
MEDIUMTEXT is max ~16 M chars; the indexes make use of the first 255 chars (here) and you can store "~arbitrarily long text" in those string based MLMD properties.
This is working fine.
- When instead you attempt to store a string based MLMD property backed by PostgreSQL,
TEXT is max ~536 M chars; however, the index by default would limit you to merely ~2690 characters because is not taking the substring approach above (here) and as a net result because of default's btree limit (here) you can store at max ~2690 chars.
To me, this seems to indicate a potential typo/overlook/misconfiguration of the PostreSQL index, because as of today can store in practice only 2k chars of text when MLMD backed by PostgreSQL, when practically MLMD backed by MySQL you could do 1000x magnitude.
Potential solutions provided in PR: #195
MEDIUMTEXTis max ~16 M chars; the indexes make use of the first 255 chars (here) and you can store "~arbitrarily long text" in those string based MLMD properties.This is working fine.
TEXTis max ~536 M chars; however, the index by default would limit you to merely ~2690 characters because is not taking the substring approach above (here) and as a net result because of default'sbtreelimit (here) you can store at max ~2690 chars.To me, this seems to indicate a potential typo/overlook/misconfiguration of the PostreSQL index, because as of today can store in practice only 2k chars of text when MLMD backed by PostgreSQL, when practically MLMD backed by MySQL you could do 1000x magnitude.
Potential solutions provided in PR: #195