tateisu/gist:390eaf6a4abc84a8c339677691638316

## gistfile1.txt
SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses"
WHERE "statuses"."account_id" = 1540 AND "statuses"."visibility" IN (0, 1) AND (
statuses.reply = false OR statuses.in_reply_to_account_id = statuses.account_id
) ORDER BY "statuses"."id" DESC LIMIT 40

通常のユーザだと特に遅くもないクエリだが、ユーザ1540は特別に遅い。

ANALYZEはpgheroからだとタイムアウトする。
psqlから実行すると以下の結果が得られた

postgres=# explain analyze SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses"
postgres-# WHERE "statuses"."account_id" = 1540 AND "statuses"."visibility" IN (0, 1) AND (
postgres(# statuses.reply = false OR statuses.in_reply_to_account_id = statuses.account_id
postgres(# ) ORDER BY "statuses"."id" DESC LIMIT 40;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..64.88 rows=40 width=16) (actual time=157432.529..157452.145 rows=40 loops=1)
   ->  Index Scan Backward using statuses_pkey on statuses  (cost=0.43..401453.10 rows=249147 width=16) (actual time=157432.524..157452.089 rows=40 loops=1)
         Filter: ((visibility = ANY ('{0,1}'::integer[])) AND ((NOT reply) OR (in_reply_to_account_id = account_id)) AND (account_id = 1540))
         Rows Removed by Filter: 454938
 Planning time: 3.128 ms
 Execution time: 157452.331 ms
(6 rows)

1540のユーザは大量の投稿を(おそらくbot的に)行っていた。9月16日に活動を停止した。
投稿量が多すぎて index_statuses_on_account_id_id ではなく statuses_pkey が選択されてしまう

postgres=# select count(*) from statuses where account_id=1540;
 count
--------
 272804
(1 row)

postgres=# select count(*) from statuses ;
  count
---------
 3324508
(1 row)

しかし9/16以降は活動していないので、 statuses_pkey を新しい順に読むと明らかに読み飛ばしが多く遅くなる。
	SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses"
	WHERE "statuses"."account_id" = 1540 AND "statuses"."visibility" IN (0, 1) AND (
	statuses.reply = false OR statuses.in_reply_to_account_id = statuses.account_id
	) ORDER BY "statuses"."id" DESC LIMIT 40

	通常のユーザだと特に遅くもないクエリだが、ユーザ1540は特別に遅い。

	ANALYZEはpgheroからだとタイムアウトする。
	psqlから実行すると以下の結果が得られた

	postgres=# explain analyze SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses"
	postgres-# WHERE "statuses"."account_id" = 1540 AND "statuses"."visibility" IN (0, 1) AND (
	postgres(# statuses.reply = false OR statuses.in_reply_to_account_id = statuses.account_id
	postgres(# ) ORDER BY "statuses"."id" DESC LIMIT 40;
	QUERY PLAN
	-------------------------------------------------------------------------------------------------------------------------------------------------------------
	Limit (cost=0.43..64.88 rows=40 width=16) (actual time=157432.529..157452.145 rows=40 loops=1)
	-> Index Scan Backward using statuses_pkey on statuses (cost=0.43..401453.10 rows=249147 width=16) (actual time=157432.524..157452.089 rows=40 loops=1)
	Filter: ((visibility = ANY ('{0,1}'::integer[])) AND ((NOT reply) OR (in_reply_to_account_id = account_id)) AND (account_id = 1540))
	Rows Removed by Filter: 454938
	Planning time: 3.128 ms
	Execution time: 157452.331 ms
	(6 rows)

	1540のユーザは大量の投稿を(おそらくbot的に)行っていた。9月16日に活動を停止した。
	投稿量が多すぎて index_statuses_on_account_id_id ではなく statuses_pkey が選択されてしまう

	postgres=# select count(*) from statuses where account_id=1540;
	count
	--------
	272804
	(1 row)

	postgres=# select count(*) from statuses ;
	count
	---------
	3324508
	(1 row)

	しかし9/16以降は活動していないので、 statuses_pkey を新しい順に読むと明らかに読み飛ばしが多く遅くなる。