ロックなしで消すには WHERE IN をuniqueに対して使えばよいって言ってるけど実際は書き込みがされてなかったのはサブクエリの量を制限しないからCPUもメモリも使い切って普通のアプリの処理が出来てなかったってことでいいのかしら
ロックなしで消すには WHERE IN をuniqueに対して使えばよいって言ってるけど実際は書き込みがされてなかったのはサブクエリの量を制限しないからCPUもメモリも使い切って普通のアプリの処理が出来てなかったってことでいいのかしら
WHERE IN 使ってるのってもしかしてこれが理由かなってなってる
sql - Deleting many rows without locking them - Stack Overflow
https://stackoverflow.com/questions/3421226/deleting-many-rows-without-locking-them/3425353#3425353
100万文字、長く連載が続いてる長編小説の総文字数ぐらいでしか見ないかも
This account is not set to public on notestock.
This account is not set to public on notestock.
sql何もわからんのでexplainして invalid reference to FROM-clause entry for table "a" って怒られてしまってわからんつってる
今まで prune_objects の対象になってなかったレコード群なので新しいサーバーで実行したら変更しなくてもちゃんと終わってたんだろうなみたいな気持ちになってる
https://github.com/kphrx/pleroma/commit/a3e19ed1c73d348a575abf458e301fbb2442f95c
countは not exists にしなきゃ首が回らないぐらい重かったけど where in のサブクエリにlimitつけるならちゃんと早くなるそうだねってなった
基本的に再取得することがない過去の1500万近いレコード、消しても困りはしないんだけど定期実行するには重すぎるので時々手作業でクエリ実行して終了とかにしとくかなぁってなってる
[艦これ丼管理人]
Yashima@kancolle.social
This account is not set to public on notestock.
1500万も削除対象があるのに WHERE id IN subquery してたのか、アホすぎ
prune_objectsのクエリ書き換えても馬鹿みたいに遅いな、なんでやと思って select count(*) したら1500万って帰ってきて腰抜かしてる
WHERE IN と WHERE EXISTS で使用メモリ量が桁違いだしサブクエリの結果が大量になりうるケースで IN 使っちゃだめなんじゃないか
温かみのある手打ちサイトじゃなくてzolaによる生成だったので寒々しい
select limit 5 しただけでCPU100%使うINと10%程度で収まりながら段違いで早く結果を返す not exists 複数、明らかに後者の方が良い
database prune_objects のクエリが、 delete from activities where id in (select a.id from activities a left join objects o ... left join activities a2 ... left join users u ... where o.id is null and a2.id is null and u.id is null) みたいになってるの酷い気がするので not exists に書き換えて explain してみたけど、usersに index only scan が使われるようになったし事前にrowsがある程度出てるのでこっちのほうが早い？