From: | Eugene Morozov <eugene(at)cactus-mouse(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Forcing postgresql to use an index |
Date: | 2009-09-09 05:34:37 |
Message-ID: | 87iqfsadg2.fsf@eugenemorozov.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Tue, Sep 8, 2009 at 8:12 AM, Eugene Morozov<eugene(at)cactus-mouse(dot)com> wrote:
> OK, you need to look a little deeper at what's happening here. The
> pgsql query planner looks at a lot of things to decide if to use seq
> scan or and index. If you look at your row estimates versus actual
> rows returned, you'll see they're off, sometimes by quite a bit.
> Particularly the ones near the top of your query plans. There are a
> few things you can do to help out here. Increase default stats target
> and re-analyse, increase effective_cache_size to reflect the actual
> size of data being cached by your OS / filesystem / pgsql, and then
> lowering random_page_cost.
Thanks to all who answered. Your answers were really helpful, I've
split the query in two (couldn't make Django to use JOIN here) and was
able to speed it up by a factor of 10!
Eugene
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-09-09 10:05:22 | Re: partitioning max() sql not using index |
Previous Message | Kevin Kempter | 2009-09-08 20:53:18 | partitioning max() sql not using index |