Re: Looks like merge join planning time is too big, 55 seconds
От | Sergey Burladyan |
---|---|
Тема | Re: Looks like merge join planning time is too big, 55 seconds |
Дата | |
Msg-id | 87haf74wti.fsf@home.progtech.ru обсуждение исходный текст |
Ответ на | Re: Looks like merge join planning time is too big, 55 seconds (Sergey Burladyan <eshkinkot@gmail.com>) |
Список | pgsql-performance |
Sergey Burladyan <eshkinkot@gmail.com> writes: > Hot standby: ... > ' -> Index Only Scan using items_user_id_idx on public.items (cost=0.00..24165743.48 rows=200673143 width=8)(actual time=56064.499..56064.499 rows=1 loops=1)' > ' Output: public.items.user_id' > ' Index Cond: (public.items.user_id IS NOT NULL)' > ' Heap Fetches: 8256426' > ' Buffers: shared hit=3694164 read=6591224 written=121652' > 'Total runtime: 56064.571 ms' > > Master: > ... > ' -> Index Only Scan using items_user_id_idx on public.items (cost=0.00..24166856.02 rows=200680528 width=8)(actual time=202.756..202.756 rows=1 loops=1)' > ' Output: public.items.user_id' > ' Index Cond: (public.items.user_id IS NOT NULL)' > ' Heap Fetches: 0' > ' Buffers: shared hit=153577 read=1' > 'Total runtime: 202.786 ms' Looks like visibility map is not replicated into slave somehow? If it matters, Master was restarted yesterday, Standby was not.
В списке pgsql-performance по дате отправления: