Postgres删除/更新与Python多处理
在这种情况下，我对Postgres的行为感到好奇。
使用Python多处理，我可以在批处理中选择和插入。
选择首先独立于插入，该插入已完成后完成的一组进程。
这很好。我的问题是，为什么这种方法不适用于删除或更新？
试图删除或使用此模式进行更新时，它似乎只是挂在第二步上。据我了解，锁是在行级别而不是桌子上。什么可以解释这种行为？使用IN Operator，单行删除和删除都会发生。
例如：
DELETE FROM tablename WHERE ID = ?
或者
DELETE FROM tablename WHERE ID IN (?, ?)
我描述了这种情况发生的情况，但是正如我提到的那样，更新也是如此。对于代码的多处理部分，它只是使用pool或process的标准方法，而SQL语句则在Multiprocessing.cpu_count（） * 2 < /代码>进程。
I'm curious as to the behavior of Postgres in this instance.
Using Python multiprocessing, I can SELECT and INSERT in batches.
The SELECT runs first independently of the INSERT which is done a separate group of processes after the SELECT have all been finished.
This works perfectly fine. My question is why doesn't this approach work with DELETE or UPDATE?
When trying to DELETE or UPDATE with this pattern it seemingly just hangs on the second step. From what I understand the locks are at the row level rather than the table. What could explain this behavior? It happens with both single row DELETEs and DELETEs using the IN operator.
For example:
DELETE FROM tablename WHERE ID = ?
or
DELETE FROM tablename WHERE ID IN (?, ?)
I describe this happening with DELETE but as I mentioned the same occurs with UPDATE. For the multiprocessing part of the code, it's just a standard way of using either Pool or Process with the SQL statements divided between multiprocessing.cpu_count() * 2 processes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论