Re: Looks like merge join planning time is too big, 55 seconds

From: Sergey Burladyan <eshkinkot(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-performance\(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Looks like merge join planning time is too big, 55 seconds
Date: 2013-08-02 21:17:13
Message-ID: 87haf74wti.fsf@home.progtech.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Sergey Burladyan <eshkinkot(at)gmail(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2013-08-02 21:27:41 Re: subselect requires offset 0 for good performance.
Previous Message Kevin Grittner 2013-08-02 21:03:28 Re: to many locks held