Re: the big picture for index-only scans

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: the big picture for index-only scans
Date: 2011-06-20 00:46:56
Message-ID: BANLkTimU811byPejGXSdPX2uxTeRqhUS=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 19, 2011 at 7:59 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Jun19, 2011, at 23:16 , Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>>> On Jun19, 2011, at 20:40 , Robert Haas wrote:
>>>> 2. Since VACUUM and ANALYZE often run together, we will be estimating
>>>> the percentage of rows on all-visible pages just at the time when that
>>>> percentage is highest.  This is not exactly wonderful, either...
>>>
>>> Hm, doesn't autovacuum run ANALYZE quite a bit more frequently than
>>> VACUUM by default?
>>
>> The autoanalyze threshold is, by default, 10%; and the autovacuum
>> threshold, 20%.
>
> Hm, so you could ignore (or rather dampen) the results of
> VACUUM+ANALYZE and rely on the ANALYZE-only runs to keep
> the estimate correct. Still doesn't sound that bad...

Yeah, there are a lots of possible approaches. You could try to keep
a count of how many visibility map bits had been cleared since the
last run... and either adjust the estimate directly or use it to
trigger an ANALYZE (or some limited ANALYZE that only looks at
visibility map bits). You could gather statistics on how often the
queries that are actually running are finding the relevant visibility
map bits set, and use that to plan future queries. You could do what
you're suggesting... and there are probably other options as well.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-20 00:49:19 Re: [WIP] cache estimates, cache access cost
Previous Message Greg Smith 2011-06-20 00:30:24 Re: [WIP] cache estimates, cache access cost