From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Devel 9.2] Index-only scan in count aggregation |
Date: | 2012-04-18 16:53:17 |
Message-ID: | CA+TgmobTYjFwKH83bmP+DEkxtDM4mqTChBcf6ShqM2d-qNXDew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 18, 2012 at 12:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Apr 18, 2012 at 12:40 PM, Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com> wrote:
>>> I'm not sure what you're unhappy about. It seems that the query
>>> planner picked the fastest plan (a sequential scan) and then when you
>>> disabled that it picked the second-fastest plan (an index-only scan).
>>>
>>> The index-only scan would have a chance of beating the sequential scan
>>> if the table had been recently vacuumed, but not in the case where
>>> every row is going to require a heap fetch.
>>
>> Oh, I see now. Honestly, I thought it wasn't necessary to make a heap
>> fetch. The table
>> doesn't have any modifications, but with the vacuum the cost changed.
>
> Ah, I see. Yeah, I think you're not going to be the first person to
> not realize that, especially since we haven't changed the rules for
> autovacuuming, and therefore you can't count on autovac to correct the
> problem for you. :-(
And by "the first person" I of course meant "the last person".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-04-18 17:02:24 | Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments |
Previous Message | Robert Haas | 2012-04-18 16:52:49 | Re: [Devel 9.2] Index-only scan in count aggregation |