From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Karl Larsson <karl(dot)larsson47(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: seq scan instead of index scan |
Date: | 2009-12-18 00:11:19 |
Message-ID: | dcc563d10912171611j57031d1fv34d4154797efa260@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Karl Larsson | 2009-12-18 01:10:32 | Re: seq scan instead of index scan |
Previous Message | Greg Smith | 2009-12-18 00:10:56 | Re: seq scan instead of index scan |