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
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 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
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 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
>
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 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
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
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
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
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
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 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
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
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
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
>
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 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
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
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_usage_counts() function. This function returns a row per
poss
20 matches
Mail list logo
