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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: to many locks held
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: subselect requires offset 0 for good performance.