From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | dforum <dforums(at)vieonet(dot)com> |
Cc: | Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: GiST index performance |
Date: | 2009-04-17 01:22:08 |
Message-ID: | 49E7D9C0.90901@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
dforum wrote:
> hello,
>
> there is other performance problem on this request.
>
> If you analyse query plan, you see that most of the time are lost during
> sequencial scan, and you have 2 seq scan.
>
> You have to create other indexes to match the request.
>
> Postgresq is totally dependant on index to reach is performance.
That depends a lot on your queries. Sometimes a sequential scan is a
faster and better choice. It may also be faster for small tables.
I've usually found that when I (for performance testing purposes) force
the planner to an index scan instead of its preferred sequential scan,
the query runs slower than it did with a sequential scan.
Sure, there are queries that are horrifyingly slow without appropriate
indexes, but I wouldn't go so far as to say that Pg is totally dependent
on indexes to perform well. It depends a lot on the query.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad Arkhipov | 2009-04-17 04:50:15 | Optimizer's issue |
Previous Message | Kris Jurka | 2009-04-17 01:02:04 | Re: No hash join across partitioned tables? |