From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com> |
Cc: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres 9.0 has a bias against indexes |
Date: | 2011-01-27 16:40:47 |
Message-ID: | 17268.1296146447@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
David Wilson <david(dot)t(dot)wilson(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2011-01-27 16:51:46 | Re: Running PostgreSQL as fast as possible no matter the consequences |
Previous Message | Igor Neyman | 2011-01-27 16:17:46 | Re: Real vs Int performance |