ロックなしで消すには WHERE IN をuniqueに対して使えばよいって言ってるけど実際は書き込みがされてなかったのはサブクエリの量を制限しないからCPUもメモリも使い切って普通のアプリの処理が出来てなかったってことでいいのかしら

SQLのハック、奇怪

WHERE IN 使ってるのってもしかしてこれが理由かなってなってる

sql - Deleting many rows without locking them - Stack Overflow
https://stackoverflow.com/questions/3421226/deleting-many-rows-without-locking-them/3425353#3425353

30万ぐらいにしとくと文庫本1冊分ぐらいの文字数が入る

100万文字、長く連載が続いてる長編小説の総文字数ぐらいでしか見ないかも

pleromaはハードコードされた上限は基本的にない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Vi IMproved

sql何もわからんのでexplainして invalid reference to FROM-clause entry for table "a" って怒られてしまってわからんつってる

rustのtlsといえばrustls

今まで prune_objects の対象になってなかったレコード群なので新しいサーバーで実行したら変更しなくてもちゃんと終わってたんだろうなみたいな気持ちになってる

https://github.com/kphrx/pleroma/commit/a3e19ed1c73d348a575abf458e301fbb2442f95c

countは not exists にしなきゃ首が回らないぐらい重かったけど where in のサブクエリにlimitつけるならちゃんと早くなるそうだねってなった

基本的に再取得することがない過去の1500万近いレコード、消しても困りはしないんだけど定期実行するには重すぎるので時々手作業でクエリ実行して終了とかにしとくかなぁってなってる

このアカウントは、notestockで公開設定になっていません。

1500万も削除対象があるのに WHERE id IN subquery してたのか、アホすぎ

prune_objectsのクエリ書き換えても馬鹿みたいに遅いな、なんでやと思って select count(*) したら1500万って帰ってきて腰抜かしてる

これに対する感想

https://pl.kpherox.dev/notice/AnS0v3jnxKQiVR7ypU

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がある程度出てるのでこっちのほうが早い？