Re: Why is PostgreSQL not using my index?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Christian Roche <Christian(dot)Roche(at)workshare(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why is PostgreSQL not using my index?
Date: 2015-01-27 14:11:17
Message-ID: CAHyXU0zZzhxAWOO4mYP4BQcdD5gnjGvMZyCVfxGAOLNYfOsZzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jan 26, 2015 at 10:32 AM, Christian Roche
<Christian(dot)Roche(at)workshare(dot)com> wrote:
> Bitmap Heap Scan on mixpanel_events_201409 (cost=7663.36..1102862.70
> rows=410022 width=949)
>
> Recheck Cond: (event_id = ANY
> ('{3,4,5,6,7,8,9,10,11,373,375,376,318}'::integer[]))
>
> -> Bitmap Index Scan on mixpanel_idx_event_201409 (cost=0.00..7560.85
> rows=410022 width=0)
>
> Index Cond: (event_id = ANY
> ('{3,4,5,6,7,8,9,10,11,373,375,376,318}'::integer[]))
>
>
> But when I try to join the lookup table and select from it, the index is
> dismissed for a full table scan with a catastrophic effect on performance:

Better to post 'explain analyze' times than 'explain', so we can get a
better understanding of what 'catastrophic' means. Other frequently
overlooked planner influencing settings are effective_cache_size,
which estimates amount memory available for caching and work_mem.
effective_cache_size in particular is often dreadfully underset making
the server thing it's going to have to do expensive random i/o to
facilitate nestloops and will therefore tend to avoid them.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tomas Vondra 2015-01-28 19:48:02 Re: working around JSONB's lack of stats?
Previous Message Josh Berkus 2015-01-27 07:06:09 working around JSONB's lack of stats?