Re: seq scan instead of index scan

On Thu, Dec 17, 2009 at 4:46 PM, Karl Larsson <karl(dot)larsson47(at)gmail(dot)com> wrote:
>
>
> On Fri, Dec 18, 2009 at 12:26 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
> wrote:
>>
>> On Thu, Dec 17, 2009 at 4:22 PM, Karl Larsson <karl(dot)larsson47(at)gmail(dot)com>
>> wrote:
>> > Hello.
>> >
>> > I have a problem I don't understand. I hope it's a simple problem and
>> > I'm
>> > just stupid.
>> >
>> > When I make a subquery Postgres don't care about my indexes and makes
>> > a seq scan instead of a index scan. Why?
>>
>> PostgreSQL uses an intelligent query planner that predicets how many
>> rows it will get back for each plan and chooses accordingly.  Since a
>> few dozen rows will all likely fit in the same block, it's way faster
>> to sequentially scan the table than to use an index scan.
>>
>> Note that pgsql always has to go back to the original table to get the
>> rows anyway, since visibility info is not stored in the indexes.
>
> I forgot to mention  that I have a reel problem with 937(and growing) rows
> of data. My test tables
> and test query is just to exemplify my problem. But I'll extend table_two
> and see if it change anything.

Best bet is to post the real problem, not a semi-representational made
up one. Unless the made up "test case" is truly representative and
recreates the failure pretty much the same was as the original.