To: David Wilson <david.t.wilson@gmail.com>
cc: Mladen Gogala <mladen.gogala@vmsinfo.com>,
 Kenneth Marshall <ktm@rice.edu>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Postgres 9.0 has a bias against indexes 
In-reply-to: <AANLkTinjSQ4+56fZtDELXZ7uU49evc8U-Z0WV6U4FH6U@mail.gmail.com> 
References: <4D419214.8060003@vmsinfo.com>
	<20110127154539.GE6475@aart.is.rice.edu>
	<4D41959B.8020901@vmsinfo.com>
	<AANLkTinjSQ4+56fZtDELXZ7uU49evc8U-Z0WV6U4FH6U@mail.gmail.com>
Comments: In-reply-to David Wilson <david.t.wilson@gmail.com>
	message dated "Thu, 27 Jan 2011 11:09:15 -0500"
Date: Thu, 27 Jan 2011 11:40:47 -0500
Message-ID: <17268.1296146447@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

David Wilson <david.t.wilson@gmail.com> writes:
> You're still using a 14 row table, though.

Exactly.  Please note what it says in the fine manual:

    It is worth noting that EXPLAIN results should not be extrapolated
    to situations other than the one you are actually testing; for
    example, results on a toy-sized table cannot be assumed to apply to
    large tables. The planner's cost estimates are not linear and so it
    might choose a different plan for a larger or smaller table. An
    extreme example is that on a table that only occupies one disk page,
    you'll nearly always get a sequential scan plan whether indexes are
    available or not. The planner realizes that it's going to take one
    disk page read to process the table in any case, so there's no value
    in expending additional page reads to look at an index.


			regards, tom lane