Subject: Re: shared-memory based stats collector
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Magnus Hagander
 <magnus@hagander.net>, Tom Lane <tgl@sss.pgh.pa.us>,
 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <20180629.173418.190173462.horiguchi.kyotaro@lab.ntt.co.jp>
 <CA+TgmoYQhr30eAcgJCi1v0FhA+3RP1FZVnXqSTLe=6fHy9e5oA@mail.gmail.com>
 <20180703.190144.222427588.horiguchi.kyotaro@lab.ntt.co.jp>
 <67470.1530739431@sss.pgh.pa.us>
 <CABUevEwXO-8so0gpkz2C-rExaVJcioi-wj-R9nf+F9Yr3He2uw@mail.gmail.com>
 <CA+TgmoZz9wHf08Ww8d7uQbGJ8CFzkv4KnP23ZYV312_VJS=Fog@mail.gmail.com>
 <20180706185750.b6h5cwif53zfieu7@alap3.anarazel.de>
 <608c6c72-96ef-f002-65fe-6889cc37db99@commandprompt.com>
 <CA+TgmoYbd9h3cisB_=p=ASg9o_vJm8rmW7VZs-TS0Mu947AxtQ@mail.gmail.com>
From: "Joshua D. Drake" <jd@commandprompt.com>
Organization: Command Prompt, Inc.
Message-ID: <97b73d3f-a093-1edd-624d-28ff548c4a80@commandprompt.com>
Date: Fri, 6 Jul 2018 12:46:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmoYbd9h3cisB_=p=ASg9o_vJm8rmW7VZs-TS0Mu947AxtQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 07/06/2018 12:34 PM, Robert Haas wrote:
> On Fri, Jul 6, 2018 at 3:02 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> Will stats, if we move toward the suggested changes be "less" accurate than
>> they are now? We already know that stats are generally not accurate but they
>> are close enough. If we move toward this change will it still be close
>> enough?
> There proposed change would have no impact at all on the long-term
> accuracy of the statistics.  It would just mean that there would be
> race conditions when reading them, so that for example you would be
> more likely to see a count of heap scans that doesn't match the count
> of index scans, because an update arrives in between when you read the
> first value and when you read the second one.  I don't see that
> mattering a whole lot, TBH, but maybe I'm missing something.

I agree that it probably isn't a big deal. Generally speaking when we 
look at stats it is to get an "idea" of what is going on. We don't care 
if we are missing an increase/decrease of 20 of any particular value 
within stats. Based on this and what Andres said, it seems like a net 
win to me.

JD

>

-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****