| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Kenneth Marshall" <ktm(at)rice(dot)edu>, "Mladen Gogala" <mladen(dot)gogala(at)vmsinfo(dot)com> |
| Cc: | "David Wilson" <david(dot)t(dot)wilson(at)gmail(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Igor Neyman" <ineyman(at)perceptron(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Postgres 9.0 has a bias against indexes |
| Date: | 2011-01-27 21:43:29 |
| Message-ID: | 4D4192A10200002500039EEA@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> wrote:
> Yes, Oracle can be forced into doing a sequential scan and it is
> actually faster than an index scan:
And PostgreSQL can be coerced to use an indexed scan. Its plans are
cost-based, with user configurable cost factors; so if you tell it
that seq_page_cost and random_page_cost are both equal to some
really low value (like 0.001), you'll get an index scan. Part of
the process of tuning PostgreSQL is to discover the relative
*actual* costs on *your environment* (which is largely dependent on
the degree of caching of the active portion of your database). When
you get your costing factors to approximate reality, the optimizer
will do a pretty good job of picking the fastest plan.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Schnabel | 2011-01-27 23:01:03 | How to best use 32 15k.7 300GB drives? |
| Previous Message | Mladen Gogala | 2011-01-27 21:33:38 | Re: Postgres 9.0 has a bias against indexes |