You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NodeNorm was designed with Redis databases because it needed to normalize identifiers on the fly, and so needed to be very fast. This requirement makes it quite expensive to run it for Translator. We should experiment with replacing the Redis databases with another database engine (I like PostgreSQL) and test it, ideally generating some kind of cost-to-speed curve.
Note that the goal is to CHECK whether this approach would be feasible: we don't actually want to redesign NodeNorm unless we can pre-emptively show that they would be useful -- the simplest approach might be to build some kind of simple frontend on top of a PostgreSQL databases loaded from the DuckDB export we currently build, and then compare that with the Redis-based NodeNorm.
The text was updated successfully, but these errors were encountered:
NodeNorm was designed with Redis databases because it needed to normalize identifiers on the fly, and so needed to be very fast. This requirement makes it quite expensive to run it for Translator. We should experiment with replacing the Redis databases with another database engine (I like PostgreSQL) and test it, ideally generating some kind of cost-to-speed curve.
Note that the goal is to CHECK whether this approach would be feasible: we don't actually want to redesign NodeNorm unless we can pre-emptively show that they would be useful -- the simplest approach might be to build some kind of simple frontend on top of a PostgreSQL databases loaded from the DuckDB export we currently build, and then compare that with the Redis-based NodeNorm.
The text was updated successfully, but these errors were encountered: