From: | "Dave Dutcher" <dave(at)tridecap(dot)com> |
---|---|
To: | "'cluster'" <skrald(at)amossen(dot)dk>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query only slow on first run |
Date: | 2007-11-27 23:47:31 |
Message-ID: | 05ae01c8314f$e0a86990$8e00a8c0@tridecap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> -----Original Message-----
> From: cluster
>
> If I disable the nested loops, the query becomes *much* slower.
>
> A thing that strikes me is the following. As you can see I have the
> constraint: q.status = 1. Only a small subset of the data set
> has this status. I have an index on q.status but for some
> reason this is not used. Instead the constraint are ensured
> with a "Filter: (q.status = 1)"
> in an index scan for the primary key in the "q" table. If the
> small subset having q.status = 1 could be isolated quickly
> using an index, I would expect the query to perform better. I
> just don't know why the planner doesn't use the index on q.status.
>
What version of Postgres are you using? Do you know what your
join_collapse_limit is set to?
You might be able to force it to scan for questions with a status of 1 first
to see if it helps by changing the FROM clause to:
FROM posts p, question_tags qt, (SELECT * FROM questions WHERE status = 1
OFFSET 0) q
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-11-28 00:25:54 | Re: Query only slow on first run |
Previous Message | Steinar H. Gunderson | 2007-11-27 23:38:33 | Re: Query only slow on first run |