From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
---|---|
To: | Mathieu De Zutter <mathieu(at)dezutter(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Choice of bitmap scan over index scan |
Date: | 2010-01-11 10:36:50 |
Message-ID: | alpine.DEB.2.00.1001111029040.25000@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 11 Jan 2010, Mathieu De Zutter wrote:
> > seq_page_cost = 0.1
> > random_page_cost = 0.1
> So if this query usually does *not* hit the cache, it will be probably faster if I leave
> it like that? While testing a query I execute it that much that it's always getting into
> the cache. However, since other applications run on the same server, I think that
> infrequently used data gets flushed after a while, even if the DB could fit in the RAM.
Postgres is being conservative. The plan it uses (bitmap index scan) will
perform much better than an index scan when the data is not in the cache,
by maybe an order of magnitude, depending on your hardware setup.
The index scan may perform better at the moment, but the bitmap index scan
is safer.
Matthew
--
Change is inevitable, except from vending machines.
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre Frédéric Caillaud | 2010-01-11 11:23:53 | Re: Choice of bitmap scan over index scan |
Previous Message | Mathieu De Zutter | 2010-01-11 08:36:40 | Re: Choice of bitmap scan over index scan |