Re: 9.2 and index only scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: 9.2 and index only scans
Date: 2012-08-26 19:34:29
Message-ID: 15248.1346009669@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer <spam_eater(at)gmx(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2012-08-26 19:42:45 Re: 9.2 and index only scans
Previous Message Jeff Janes 2012-08-26 18:45:48 Re: 9.2 and index only scans