Re: 9.2 and index only scans

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 9.2 and index only scans
Date: 2012-08-26 18:45:48
Message-ID: CAMkU=1w=zeHF7B_Uf9_kvQm4WLL95BpfT8O0=uBhLLyNhZJrOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> Tom Lane wrote on 26.08.2012 16:31:
>
>> Thomas Kellerer <spam_eater(at)gmx(dot)net> writes:
>>>
>>> I'm playing around with 9.2 beta4 and was looking into the new Index Only
>>> Scan feature.
>>> I was a bit surprised that a "count(*)" query does not use an index.
>>
>>
>> Works for me. However, the cost estimate for that is heavily dependent
>> on how much of the table is known all-visible. If the table is getting
>> a lot of churn, or even just hasn't been vacuumed since it quiesced,
>> the planner will prefer a seqscan for this --- and it will be right.
>>
>
> Hmm. So it's something with my environment.
>
> Should the following setup qualify for an index scan?

The seq scan is estimated to use sequential reads, while the
index-only scan is estimated to use random reads (because the index is
scanned in logical order, not physical order).

If you set random_page_cost equal to seq_page_cost, that would
artificially favor the index only scan.

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

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-08-26 19:34:29 Re: 9.2 and index only scans
Previous Message Moshe Jacobson 2012-08-26 18:26:26 Renaming tables and their indexes simultaneously