On Mon, 30 Jan 2023 at 18:31, Nathan Bossart wrote:
>
> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> distributions for various workloads, and he mentioned that it would be nice
> to have an easy way to do $SUBJECT. I've attached a patch that adds a
> pg_buffercache
On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart wrote:
> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> distributions for various workloads, and he mentioned that it would be nice
> to have an easy way to do $SUBJECT. I've attached a patch that adds a
> pg_buffercache
Robert Haas writes:
> On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart
> wrote:
>> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
>> distributions for various workloads, and he mentioned that it would be nice
>> to have an easy way to do $SUBJECT.
> I'm skeptical that
On Tue, Apr 4, 2023 at 2:40 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart
> > wrote:
> >> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> >> distributions for various workloads, and he mentioned that it would be nice
>
Hi,
On 2023-04-04 14:14:36 -0400, Greg Stark wrote:
> Tom expressed skepticism that there's wide interest here. It seems as
> much from the lack of response. But perhaps that's just because people
> don't understand what the importance of this info is -- I certainly
> don't :)
pg_buffercache has
Hi,
On 2023-04-04 14:31:36 -0400, Robert Haas wrote:
> On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart
> wrote:
> > My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> > distributions for various workloads, and he mentioned that it would be nice
> > to have an easy way to
On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> > I'm skeptical that pg_buffercache_summary() is a good idea at all
>
> Why? It's about two orders of magnitude faster than querying the equivalent
> data by aggregating in SQL. And knowing how many free and dirty buffers are
> over time is som
On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
>> > Replacing that with a six-element integer array would be a clear
>> > improvement
>> > and, IMHO, better than adding yet another function to the extension.
>>
>> I'd have no iss
On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart wrote:
> On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> > On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> >> > Replacing that with a six-element integer array would be a clear
> >> > improvement
> >> > and, IMHO, better than add
Robert Haas writes:
> On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart
> wrote:
>> The six-element array approach won't show the number of dirty and pinned
>> buffers for each usage count, but I'm not sure that's a deal-breaker.
>> Barring objections, I'll post an updated patch shortly with that ap
Hi,
On 2023-04-05 15:00:20 -0400, Robert Haas wrote:
> On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart
> wrote:
> > On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> > > On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> > >> > Replacing that with a six-element integer array would
On Wed, Apr 05, 2023 at 03:07:10PM -0400, Tom Lane wrote:
> Seems to me that six rows would be easier to aggregate manually.
> An array column seems less SQL-ish and harder to manipulate.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote:
> I would not mind having a separate function returning 6 rows, if we really
> want that, but making pg_buffercache_summary() return 6 rows would imo make it
> less useful for getting a quick overview. At least I am not that quick summi
Nathan Bossart writes:
> On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote:
>> I would not mind having a separate function returning 6 rows, if we really
>> want that, but making pg_buffercache_summary() return 6 rows would imo make
>> it
>> less useful for getting a quick overview. A
On Wed, Apr 5, 2023 at 4:16 PM Tom Lane wrote:
> Nathan Bossart writes:
> > On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote:
> >> I would not mind having a separate function returning 6 rows, if we really
> >> want that, but making pg_buffercache_summary() return 6 rows would imo
>
Robert Haas writes:
> On Wed, Apr 5, 2023 at 4:16 PM Tom Lane wrote:
>> Having two functions doesn't seem unreasonable to me either.
>> Robert spoke against it to start with, does he still want to
>> advocate for that?
> My position is that if we replace the average usage count with
> something
On Thu, Apr 06, 2023 at 01:32:35PM -0400, Tom Lane wrote:
> There seems to be enough support for the existing summary function
> definition to leave it as-is; Andres likes it for one, and I'm not
> excited about trying to persuade him he's wrong. But a second
> slightly-less-aggregated summary fun
Nathan Bossart writes:
> On Thu, Apr 06, 2023 at 01:32:35PM -0400, Tom Lane wrote:
>> There seems to be enough support for the existing summary function
>> definition to leave it as-is; Andres likes it for one, and I'm not
>> excited about trying to persuade him he's wrong. But a second
>> slight
On Fri, Apr 07, 2023 at 02:29:31PM -0400, Tom Lane wrote:
> I'm not sure if there is consensus for 0002, but I reviewed and pushed
> 0001. I made one non-cosmetic change: it no longer skips invalid
> buffers. Otherwise, the row for usage count 0 would be pretty useless.
> Also it seemed to me tha
19 matches
Mail list logo
