On Thu, Dec 17, 2009 at 4:46 PM, Karl Larsson <karl.larsson47@xxxxxxxxx> wrote: > > > On Fri, Dec 18, 2009 at 12:26 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> On Thu, Dec 17, 2009 at 4:22 PM, Karl Larsson <karl.larsson47@xxxxxxxxx> >> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
