Re: shared-memory based stats collector

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: shared-memory based stats collector
Date: 2018-07-06 19:02:39
Message-ID: 608c6c72-96ef-f002-65fe-6889cc37db99@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/06/2018 11:57 AM, Andres Freund wrote:
> On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
>> I think we also have to ask ourselves in general whether snapshots of
>> this data are worth what they cost. I don't think anyone would doubt
>> that a consistent snapshot of the data is better than an inconsistent
>> view of the data if the costs were equal. However, if we can avoid a
>> huge amount of memory usage and complexity on large systems with
>> hundreds of backends by ditching the snapshot requirement, then we
>> should ask ourselves how important we think the snapshot behavior
>> really is.
> Indeed. I don't think it's worthwhile major additional memory or code
> complexity in this situation. The likelihood of benefitting from more /
> better stats seems far higher than a more accurate view of the stats -
> which aren't particularly accurate themselves. They don't even survive
> crashes right now, so I don't think the current accuracy is very high.

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?

JD

>
> Greetings,
>
> Andres Freund
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-07-06 19:14:01 Re: Explain buffers wrong counter with parallel plans
Previous Message Andres Freund 2018-07-06 18:57:50 Re: shared-memory based stats collector