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
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 |