On 2023-10-30 08:25:17 +0900, Michael Paquier wrote:
> On Fri, Oct 27, 2023 at 09:45:52AM +0200, Drouvot, Bertrand wrote:
> > Done in V8 attached (pgindent has been run on pgstatfuncs.c and
> > pgstat_relation.c).
>
> And applied that after editing a bit the comments.
Thank you both!
On Fri, Oct 27, 2023 at 09:45:52AM +0200, Drouvot, Bertrand wrote:
> Done in V8 attached (pgindent has been run on pgstatfuncs.c and
> pgstat_relation.c).
And applied that after editing a bit the comments.
--
Michael
signature.asc
Description: PGP signature
On Fri, Oct 27, 2023 at 09:45:52AM +0200, Drouvot, Bertrand wrote:
> Oh I see, yeah I do agree to set tablestatus->trans to NULL to avoid
> any undesired interference with tabentry->trans.
>
> Done in V8 attached (pgindent has been run on pgstatfuncs.c and
> pgstat_relation.c).
LGTM.
--
Michael
Hi,
On 10/27/23 8:07 AM, Michael Paquier wrote:
The part that I found disturbing is here:
+ tabentry = (PgStat_TableStatus *) entry_ref->pending;
+ tablestatus = palloc(sizeof(PgStat_TableStatus));
+ *tablestatus = *tabentry;
This causes tablestatus->trans to point to the sam
On Thu, Oct 26, 2023 at 10:04:25AM +0200, Drouvot, Bertrand wrote:
> By "used in an unexpected way in the future", what do you mean exactly? Do
> you mean
> the caller forgetting it is working on a copy and then could work with
> "stale" counters?
(Be careful about the code indentation.)
The par
Hi,
On 3/27/23 8:35 AM, Michael Paquier wrote:
On Fri, Mar 24, 2023 at 08:00:44PM -0700, Andres Freund wrote:
I don't understand what we're optimizing for here. These functions are very
very very far from being a hot path. The xact functions are barely ever
used. Compared to the cost of query e
On Tue, Apr 04, 2023 at 09:04:34PM +0900, Michael Paquier wrote:
> This addition looks OK for me. Thanks for the patch!
Okay, finally done. One part that was still not complete to me in
light of the information ddfc2d9 has removed is that the number of
physical reads could be lower than the repo
On Wed, Mar 29, 2023 at 07:44:20AM +0200, Drouvot, Bertrand wrote:
> Please find a draft attached.
This addition looks OK for me. Thanks for the patch!
--
Michael
signature.asc
Description: PGP signature
Hi,
On 3/29/23 2:09 AM, Michael Paquier wrote:
On Tue, Mar 28, 2023 at 05:43:26PM +0900, Kyotaro Horiguchi wrote:
No. Fine by me, except that "block read requests" seems to suggest
kernel read() calls, maybe because it's not clear whether "block"
refers to our buffer blocks or file blocks to me
On Tue, Mar 28, 2023 at 05:43:26PM +0900, Kyotaro Horiguchi wrote:
> No. Fine by me, except that "block read requests" seems to suggest
> kernel read() calls, maybe because it's not clear whether "block"
> refers to our buffer blocks or file blocks to me.. If it is generally
> clear, I'm fine with
At Tue, 28 Mar 2023 15:16:36 +0900, Michael Paquier wrote
in
> On Tue, Mar 28, 2023 at 07:49:45AM +0200, Drouvot, Bertrand wrote:
> > What about something like?
> >
> > for pg_stat_get_xact_blocks_fetched(): "block read requests for table or
> > index, in the current
> > transaction. This numb
On Tue, Mar 28, 2023 at 07:49:45AM +0200, Drouvot, Bertrand wrote:
> What about something like?
>
> for pg_stat_get_xact_blocks_fetched(): "block read requests for table or
> index, in the current
> transaction. This number minus pg_stat_get_xact_blocks_hit() gives the number
> of kernel
> read(
Hi,
On 3/28/23 7:23 AM, Michael Paquier wrote:
On Tue, Mar 28, 2023 at 12:36:15PM +0900, Kyotaro Horiguchi wrote:
I found that commit ddfc2d9a37 removed the descriptions for
pg_stat_get_blocks_fetched and pg_stat_get_blocks_hit. Right before
that commit, monitoring.sgml had these lines:
-
On Tue, Mar 28, 2023 at 12:36:15PM +0900, Kyotaro Horiguchi wrote:
> I found that commit ddfc2d9a37 removed the descriptions for
> pg_stat_get_blocks_fetched and pg_stat_get_blocks_hit. Right before
> that commit, monitoring.sgml had these lines:
>
> - pg_stat_get_blocks_fetched minus
> -
At Tue, 28 Mar 2023 07:38:25 +0900, Michael Paquier wrote
in
> On Mon, Mar 27, 2023 at 10:24:46AM -0400, Melanie Plageman wrote:
> > I do like/prefer "block read requests" and
> > "blocks requested found in cache"
> > Though, now I fear my initial complaint may have been a bit pedantic.
>
> Tha
On Mon, Mar 27, 2023 at 10:24:46AM -0400, Melanie Plageman wrote:
> I do like/prefer "block read requests" and
> "blocks requested found in cache"
> Though, now I fear my initial complaint may have been a bit pedantic.
That's fine. Let's ask for extra opinions, then.
So, have others an opinion t
On Wed, Mar 22, 2023 at 6:42 PM Michael Paquier wrote:
>
> On Wed, Mar 22, 2023 at 02:21:12PM -0400, Melanie Plageman wrote:
> > Apologies as I know this docs update has already been committed, but
> > buffers fetched and blocks fetched both feel weird to me. If you have a
> > cache hit, you don't
On Fri, Mar 24, 2023 at 08:00:44PM -0700, Andres Freund wrote:
> I don't understand what we're optimizing for here. These functions are very
> very very far from being a hot path. The xact functions are barely ever
> used. Compared to the cost of query evaluation the cost of iterating throught
> he
Hi,
On 2023-03-25 11:56:22 +0900, Michael Paquier wrote:
> On Thu, Mar 16, 2023 at 02:13:45PM +0100, Drouvot, Bertrand wrote:
> > On 3/16/23 12:46 PM, Michael Paquier wrote:
> >>> I don't think we should pay any particular attention to those 2 ones
> >>> as anyway nothing prevent the 7 others to b
On Thu, Mar 16, 2023 at 02:13:45PM +0100, Drouvot, Bertrand wrote:
> On 3/16/23 12:46 PM, Michael Paquier wrote:
>>> I don't think we should pay any particular attention to those 2 ones
>>> as anyway nothing prevent the 7 others to be called outside of the
>>> pg_stat_xact_all_tables view.
>>
>> I
On Wed, Mar 22, 2023 at 02:21:12PM -0400, Melanie Plageman wrote:
> Apologies as I know this docs update has already been committed, but
> buffers fetched and blocks fetched both feel weird to me. If you have a
> cache hit, you don't end up really "fetching" anything at all (since
> pgstat_count_bu
On Mon, Mar 20, 2023 at 6:58 AM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 3/20/23 12:43 AM, Michael Paquier wrote:
> > At the
> > end, documenting both still sounds like the best move to me.
>
> Agree.
>
> Please find attached
> v1-0001-pg_stat_get_xact_blocks_fetched-and_hit-doc.patch doing so.
>
On Wed, Mar 22, 2023 at 09:20:25AM +0100, Drouvot, Bertrand wrote:
> That said, please find enclosed V2 with "buffers fetched" suggested
> above (and no changes to "buffer hits" to keep consistency with the
> other part of the documentation mentioned up-thread).
Thanks. Applied and backpatched th
Hi,
On 3/22/23 7:44 AM, Drouvot, Bertrand wrote:
Hi,
On 3/22/23 5:45 AM, Michael Paquier wrote:
On Wed, Mar 22, 2023 at 11:37:03AM +0900, Kyotaro Horiguchi wrote:
In the original description, "buffer fetches" appears to be a plural
form of a compound noun and correct, similar to "buffer hits"
Hi,
On 3/22/23 5:45 AM, Michael Paquier wrote:
On Wed, Mar 22, 2023 at 11:37:03AM +0900, Kyotaro Horiguchi wrote:
In the original description, "buffer fetches" appears to be a plural
form of a compound noun and correct, similar to "buffer hits"
mentioned later. If we reword it, I think it shoul
On Wed, Mar 22, 2023 at 11:37:03AM +0900, Kyotaro Horiguchi wrote:
> In the original description, "buffer fetches" appears to be a plural
> form of a compound noun and correct, similar to "buffer hits"
> mentioned later. If we reword it, I think it should be "number of
> buffers fetched".
Using th
At Wed, 22 Mar 2023 10:16:12 +0900, Michael Paquier wrote
in
> On Mon, Mar 20, 2023 at 11:57:31AM +0100, Drouvot, Bertrand wrote:
> > "Buffer" sounds more appropriate to me, so the attached has been done that
> > way.
>
> This choice is OK for me.
>
> > +
> > + pg_stat_get_xac
On Mon, Mar 20, 2023 at 11:57:31AM +0100, Drouvot, Bertrand wrote:
> "Buffer" sounds more appropriate to me, so the attached has been done that
> way.
This choice is OK for me.
> +
> + pg_stat_get_xact_blocks_fetched
> +
> +pg_stat_get_xact_blocks_fetched (
> oid
Hi,
On 3/20/23 12:43 AM, Michael Paquier wrote:
At the
end, documenting both still sounds like the best move to me.
Agree.
Please find attached v1-0001-pg_stat_get_xact_blocks_fetched-and_hit-doc.patch
doing so.
I did not put the exact same wording as the one being removed in ddfc2d9, as:
On Thu, Mar 16, 2023 at 02:13:45PM +0100, Drouvot, Bertrand wrote:
> On 3/16/23 12:46 PM, Michael Paquier wrote:
>> There is no trace of them.
>> Perhaps the ones exposted through pg_stat_xact_all_tables are fine if
>> not listed.
>
> I'd be tempted to add documentation for all of them, I can look
On 3/16/23 12:46 PM, Michael Paquier wrote:
On Thu, Mar 16, 2023 at 11:32:56AM +0100, Drouvot, Bertrand wrote:
On 3/16/23 7:29 AM, Michael Paquier wrote:
From what I get with this change, the number of tuples changed by DMLs
have their computations done a bit earlier,
Thanks for looking at
On Thu, Mar 16, 2023 at 11:32:56AM +0100, Drouvot, Bertrand wrote:
> On 3/16/23 7:29 AM, Michael Paquier wrote:
>> From what I get with this change, the number of tuples changed by DMLs
>> have their computations done a bit earlier,
>
> Thanks for looking at it!
>
> Right, but note this is in a
Hi,
On 3/16/23 7:29 AM, Michael Paquier wrote:
On Mon, Mar 06, 2023 at 08:33:15AM +0100, Drouvot, Bertrand wrote:
Thanks for having looked at it!
Looking at that, I have a few comments.
+tabentry = (PgStat_TableStatus *) entry_ref->pending;
+tablestatus = palloc(sizeof(PgStat_TableSt
On Mon, Mar 06, 2023 at 08:33:15AM +0100, Drouvot, Bertrand wrote:
> Thanks for having looked at it!
Looking at that, I have a few comments.
+tabentry = (PgStat_TableStatus *) entry_ref->pending;
+tablestatus = palloc(sizeof(PgStat_TableStatus));
+*tablestatus = *tabentry;
+
[...]
+
Hi,
On 2/16/23 10:21 PM, Andres Freund wrote:
Hi,
On 2023-02-15 09:21:48 +0100, Drouvot, Bertrand wrote:
diff --git a/src/backend/utils/activity/pgstat_relation.c
b/src/backend/utils/activity/pgstat_relation.c
index f793ac1516..b26e2a5a7a 100644
--- a/src/backend/utils/activity/pgstat_relatio
Hi,
On 2023-02-15 09:21:48 +0100, Drouvot, Bertrand wrote:
> diff --git a/src/backend/utils/activity/pgstat_relation.c
> b/src/backend/utils/activity/pgstat_relation.c
> index f793ac1516..b26e2a5a7a 100644
> --- a/src/backend/utils/activity/pgstat_relation.c
> +++ b/src/backend/utils/activity/pgs
Hi,
On 2/15/23 1:56 AM, Kyotaro Horiguchi wrote:
At Tue, 14 Feb 2023 15:43:26 +0100, "Drouvot, Bertrand"
wrote in
The comment assumed that the function directly returns an entry from
shared memory, but now it copies the entry's contents into a palloc'ed
memory and stores the sums of some coun
At Tue, 14 Feb 2023 15:43:26 +0100, "Drouvot, Bertrand"
wrote in
> Oh right, my bad (the issue has been introduced in V2).
> Fixed in V4.
Great!
> > I thought that we might be able to return entry_ref->pending since the
> > callers don't call pfree on the returned pointer, but it is not great
Hi,
On 2/14/23 7:11 AM, Kyotaro Horiguchi wrote:
Isn't it ignoring the second call to pgstat_fetch_pending_entry?
Oh right, my bad (the issue has been introduced in V2).
Fixed in V4.
I thought that we might be able to return entry_ref->pending since the
callers don't call pfree on the retu
Thanks for the new version.
At Mon, 13 Feb 2023 09:58:52 +0100, "Drouvot, Bertrand"
wrote in
> Hi,
>
> On 2/13/23 8:40 AM, Kyotaro Horiguchi wrote:
> > At Mon, 13 Feb 2023 08:09:50 +0100, "Drouvot, Bertrand"
> > wrote in
> >>> I think this is useful beyond being able to generate those functio
Hi,
On 2/13/23 8:40 AM, Kyotaro Horiguchi wrote:
At Mon, 13 Feb 2023 08:09:50 +0100, "Drouvot, Bertrand"
wrote in
I think this is useful beyond being able to generate those functions
with
macros. The fact that we had to deal with transactional code in
pgstatfuncs.c
meant that a lot of the rel
At Mon, 13 Feb 2023 08:09:50 +0100, "Drouvot, Bertrand"
wrote in
>> I think this is useful beyond being able to generate those functions
>> with
>> macros. The fact that we had to deal with transactional code in
>> pgstatfuncs.c
>> meant that a lot of the relevant itnernals had to be exposed "ou
Hi,
On 2/10/23 10:46 PM, Andres Freund wrote:
Hi,
On 2023-02-09 11:38:18 +0100, Drouvot, Bertrand wrote:
Please find attached a patch proposal for $SUBJECT.
The idea has been raised in [1] by Andres: it would allow to simplify even more
the work done to
generate pg_stat_get_xact*() functions
Hi,
On 2023-02-09 11:38:18 +0100, Drouvot, Bertrand wrote:
> Please find attached a patch proposal for $SUBJECT.
>
> The idea has been raised in [1] by Andres: it would allow to simplify even
> more the work done to
> generate pg_stat_get_xact*() functions with Macros.
Thanks!
I think this is
: Andres Freund
References:
<20230210.113242.699878230551547182.horikyota@gmail.com>
<5420b28c-d33f-d25d-9f47-b06b8a237...@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5420b28c-d33f-d25d-9f47-b06b8a237...@gmail.com>
Hi,
Hi,
On 2/10/23 3:32 AM, Kyotaro Horiguchi wrote:
At Thu, 9 Feb 2023 11:38:18 +0100, "Drouvot, Bertrand"
wrote in
Hi hackers,
Please find attached a patch proposal for $SUBJECT.
The idea has been raised in [1] by Andres: it would allow to simplify
even more the work done to
generate pg_stat_
At Thu, 9 Feb 2023 11:38:18 +0100, "Drouvot, Bertrand"
wrote in
> Hi hackers,
>
> Please find attached a patch proposal for $SUBJECT.
>
> The idea has been raised in [1] by Andres: it would allow to simplify
> even more the work done to
> generate pg_stat_get_xact*() functions with Macros.
>
Hi hackers,
Please find attached a patch proposal for $SUBJECT.
The idea has been raised in [1] by Andres: it would allow to simplify even more
the work done to
generate pg_stat_get_xact*() functions with Macros.
Indeed, with the reconciliation done in find_tabstat_entry() then all the
pg_sta
48 matches
Mail list logo
