这里的所有功能请求都由我们的产品团队监控。
投票问题!
拥有高票数(通常≥10票)的想法在我们的路线图中被优先考虑。
注意:如果你想建议一个新的功能，请发布一个新的问题和标签为“功能请求”。谢谢你！
投票问题!
拥有高票数(通常≥10票)的想法在我们的路线图中被优先考虑。
注意:如果你想建议一个新的功能，请发布一个新的问题和标签为“功能请求”。谢谢你！
更新数据库异常缓慢
BalazsBarany
管理员，版主，员工，RapidMiner认证分析师，RapidMiner认证专家职位:919
独角兽
今天我遇到了一个情况，必须使用Update Database更新一个大表(很好地设置了索引)，以整数ID字段作为键(属性过滤器类型:single，属性:ID)。RapidMiner也以整数形式显示ID。
它比它应该的要慢得多:当测试一个更新时，它在几毫秒内完成，但在RapidMiner中它只需要几秒钟。
在其他软件上已经看到了这种意想不到的缓慢，我检查了数据库中的访问统计数据。该表显示了许多(并且不断增长)全表扫描，但是索引扫描的数量是恒定的。因此没有使用主键字段的索引。
使用双精度(浮点数)类型在id字段上创建第二个索引有所帮助，Update Database的吞吐量提高了1000倍，索引是根据表统计数据使用的，并且全表扫描的次数保持不变。这当然不是一个很好的解决方法，但对我来说很有帮助。
更新数据库使用“预处理语句”。在这些列中，所有列都获得指定的数据类型。根据数据库中类型之间的兼容性，如果数据类型不匹配，可以使用索引，也可以不使用索引。这里，整数索引没有用于浮点数据类型。
希望这个问题能在下一个版本中得到解决。在此之前，您可以通过在数据库中创建第二个具有适当数据类型的索引来解决这个问题，从而加快Update database的速度。
这是在PostgreSQL 10上，你的数据库可能工作不同。
它比它应该的要慢得多:当测试一个更新时，它在几毫秒内完成，但在RapidMiner中它只需要几秒钟。
在其他软件上已经看到了这种意想不到的缓慢，我检查了数据库中的访问统计数据。该表显示了许多(并且不断增长)全表扫描，但是索引扫描的数量是恒定的。因此没有使用主键字段的索引。
使用双精度(浮点数)类型在id字段上创建第二个索引有所帮助，Update Database的吞吐量提高了1000倍，索引是根据表统计数据使用的，并且全表扫描的次数保持不变。这当然不是一个很好的解决方法，但对我来说很有帮助。
更新数据库使用“预处理语句”。在这些列中，所有列都获得指定的数据类型。根据数据库中类型之间的兼容性，如果数据类型不匹配，可以使用索引，也可以不使用索引。这里，整数索引没有用于浮点数据类型。
希望这个问题能在下一个版本中得到解决。在此之前，您可以通过在数据库中创建第二个具有适当数据类型的索引来解决这个问题，从而加快Update database的速度。
这是在PostgreSQL 10上，你的数据库可能工作不同。
标记:
1
