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
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? |