From: | Karl Larsson <karl(dot)larsson47(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: seq scan instead of index scan |
Date: | 2009-12-17 23:46:32 |
Message-ID: | d7650d320912171546m66e269b4l919a881988f475bf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
/ Karl Larsson
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-12-18 00:10:56 | Re: seq scan instead of index scan |
Previous Message | Kevin Grittner | 2009-12-17 23:29:14 | Re: seq scan instead of index scan |