Skip site navigation (1) Skip section navigation (2)

Re: Query Optimization

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 (view raw or flat)
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
>

In response to

pgsql-novice by date

Next:From: Anirban PalDate: 2009-05-28 06:12:31
Subject: Re: Postgres registry access using java
Previous:From: Tom LaneDate: 2009-05-27 19:53:05
Subject: Re: Query Optimization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group