| From: | Zach Calvert <zachcalvert(at)hemerasoftware(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Sean Davis <sdavis2(at)mail(dot)nih(dot)gov>, Luiz Eduardo Cantanhede Neri <lecneri(at)gmail(dot)com>, pgsql-novice(at)postgresql(dot)org, Dan Scott <balancedtree(at)gmail(dot)com> |
| Subject: | Re: Query Optimization |
| Date: | 2009-05-27 20:49:10 |
| Message-ID: | 89af81ab0905271349x845c6cai88ec0f62336b8a18@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
Ah, I thought it was the other way. I thought a significant count of
rows WOULD switch to an index scan. Yes, this query can easily obtain
around 30-50% of the rows in the table. My apologies.
Zach Calvert
On Wed, May 27, 2009 at 2:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Zach Calvert <zachcalvert(at)hemerasoftware(dot)com> writes:
>> I've added the leaderboardid, score index and it still does the
>> sequential scan. I'm going to try inserting a few hundred thousand
>> rows and seeing if it switches to index scan.
>
> You didn't answer the critical question, which is what fraction of the
> table rows this query selects. If it's a large fraction then the
> planner never will switch to indexscan, no matter what the table size
> --- and it'll be doing the right thing. Indexscans aren't magic.
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anirban Pal | 2009-05-28 06:12:31 | Re: Postgres registry access using java |
| Previous Message | Tom Lane | 2009-05-27 19:53:05 | Re: Query Optimization |