Re: 9.2 and index only scans - Mailing list pgsql-general

From Tom Lane
Subject Re: 9.2 and index only scans
Date
Msg-id 15248.1346009669@sss.pgh.pa.us
Whole thread Raw
In response to Re: 9.2 and index only scans  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: 9.2 and index only scans  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-general
Jeff Janes <jeff.janes@gmail.com> writes:
> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer <spam_eater@gmx.net> wrote:
>> Should the following setup qualify for an index scan?

> ... Also, your filler is highly compressible, which means the table is
> much smaller than you might think.

Yeah.  I see something like 100 rows per page with this example; the
heap is 935 pages, the index 276, which makes things about a wash I/O
wise when you assume that random reads from the index will cost 4x what
sequential reads from the heap will.

You can force an index scan to occur anyway by setting enable_seqscan to
zero.  When I do that, I see an estimated cost that is marginally more
than for the seqscan, and the actual runtime is too.  I'm not sure I'd
put a whole lot of stock in that considering the example is small enough
to be fully cached, but it does show that index-only scans aren't a
magic bullet.

            regards, tom lane


pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: 9.2 and index only scans
Next
From: Pavel Stehule
Date:
Subject: Re: 9.2 and index only scans