On Wed, Jul 14, 2021 at 6:36 AM Peter Eisentraut
wrote:
>
> On 13.07.21 10:58, Magnus Hagander wrote:
> > Maybe "each distinct database id, each distinct user id, each distinct
> > query id, and whether it is a top level statement or not"?
> >
> > Or maybe "each distinct combination of database
On 13.07.21 10:58, Magnus Hagander wrote:
Maybe "each distinct database id, each distinct user id, each distinct
query id, and whether it is a top level statement or not"?
Or maybe "each distinct combination of database id, user id, query id
and whether it's a top level statement or not"?
On Tue, Jul 13, 2021 at 10:58:12AM +0200, Magnus Hagander wrote:
>
> Maybe a problem for the readability of it is that the three other
> fields are listed by their description and not by their fieldname, and
> toplevel is fieldname?
I think so too.
> Maybe "each distinct database id, each
On Tue, Jul 13, 2021 at 8:10 AM Julien Rouhaud wrote:
>
> On Mon, Jul 12, 2021 at 10:02:59PM +0200, Peter Eisentraut wrote:
> > On 22.04.21 11:23, Julien Rouhaud wrote:
> > > The statistics gathered by the module are made available via a
> > > view named pg_stat_statements. This view
>
On Mon, Jul 12, 2021 at 10:02:59PM +0200, Peter Eisentraut wrote:
> On 22.04.21 11:23, Julien Rouhaud wrote:
> > The statistics gathered by the module are made available via a
> > view named pg_stat_statements. This view
> > - contains one row for each distinct database ID, user ID
On 22.04.21 11:23, Julien Rouhaud wrote:
The statistics gathered by the module are made available via a
view named pg_stat_statements. This view
- contains one row for each distinct database ID, user ID and query
- ID (up to the maximum number of distinct statements that the
On Fri, Apr 23, 2021 at 12:40 PM Fujii Masao
wrote:
>
>
>
> On 2021/04/23 19:11, Magnus Hagander wrote:
> > On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2021/04/23 18:46, Magnus Hagander wrote:
> >>> On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao
> >>> wrote:
>
On 2021/04/23 19:11, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
wrote:
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in
On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
wrote:
>
>
>
> On 2021/04/23 18:46, Magnus Hagander wrote:
> > On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2021/04/22 18:23, Julien Rouhaud wrote:
> >>> On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
>
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
>
>
>
> On 2021/04/22 18:23, Julien Rouhaud wrote:
> > On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
> >>
> >> I found another small issue in pg_stat_statements docs. The following
> >> description in the docs should be updated so
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in the docs should be updated so that toplevel is included?
This view contains one row for each
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
>
> I found another small issue in pg_stat_statements docs. The following
> description in the docs should be updated so that toplevel is included?
>
> > This view contains one row for each distinct database ID, user ID and query
> >
On 2021/04/21 1:22, Bruce Momjian wrote:
On Wed, Apr 14, 2021 at 02:33:26PM -0400, Bruce Momjian wrote:
On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote:
On 2021-Apr-12, Bruce Momjian wrote:
OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
have not
On Wed, Apr 14, 2021 at 02:33:26PM -0400, Bruce Momjian wrote:
> On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote:
> > On 2021-Apr-12, Bruce Momjian wrote:
> >
> > > OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
> > > have not changed any of the APIs which
On Wed, Apr 14, 2021 at 02:33:26PM -0400, Bruce Momjian wrote:
> On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote:
> >
> > So I'm -1 on Julien's first proposed change, and +1 on his second
> > proposed change (the name of the first argument of
> > pgstat_report_query_id should be
On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-12, Bruce Momjian wrote:
>
> > OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
> > have not changed any of the APIs which existed before this feature was
> > added, and are called "queryid" or
On 2021-Apr-12, Bruce Momjian wrote:
> OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
> have not changed any of the APIs which existed before this feature was
> added, and are called "queryid" or "queryId" --- it is kind of a mess.
> I assume I should leave those
On Mon, Apr 12, 2021 at 10:12:46PM -0400, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote:
> > On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> > > On 2021-Apr-08, Bruce Momjian wrote:
> > >
> > > > pg_stat_activity.queryid is new, but I can
On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> > On 2021-Apr-08, Bruce Momjian wrote:
> >
> > > pg_stat_activity.queryid is new, but I can imagine cases where you would
> > > join pg_stat_activity to
On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-08, Bruce Momjian wrote:
>
> > pg_stat_activity.queryid is new, but I can imagine cases where you would
> > join pg_stat_activity to pg_stat_statements to get an estimate of how
> > long the query will take --- having
On 2021-Apr-08, Bruce Momjian wrote:
> pg_stat_activity.queryid is new, but I can imagine cases where you would
> join pg_stat_activity to pg_stat_statements to get an estimate of how
> long the query will take --- having one using an underscore and another
> one not seems odd.
OK. So far, you
On Fri, Apr 9, 2021 at 12:38:29AM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 11:34:25AM -0400, Bruce Momjian wrote:
> >
> > OK, let's get some details. First, pg_stat_statements.queryid already
> > exists (no underscore), and I don't think anyone wants to change that.
> >
> >
On Thu, Apr 08, 2021 at 11:34:25AM -0400, Bruce Momjian wrote:
>
> OK, let's get some details. First, pg_stat_statements.queryid already
> exists (no underscore), and I don't think anyone wants to change that.
>
> pg_stat_activity.queryid is new, but I can imagine cases where you would
> join
On Wed, Apr 7, 2021 at 11:27:04PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-07, Bruce Momjian wrote:
>
> > On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
>
> > > Thanks! And I agree with using query_id in the new field names while
> > > keeping
> > > queryid for
On Thu, Apr 8, 2021 at 09:31:27PM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 08:27:20PM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 08, 2021 at 05:46:07PM +0530, Amit Kapila wrote:
> > >
> > > @@ -1421,8 +1421,9 @@ ParallelQueryMain(dsm_segment *seg, shm_toc *toc)
> > > /*
On Thu, Apr 08, 2021 at 08:27:20PM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 05:46:07PM +0530, Amit Kapila wrote:
> >
> > @@ -1421,8 +1421,9 @@ ParallelQueryMain(dsm_segment *seg, shm_toc *toc)
> > /* Setting debug_query_string for individual workers */
> > debug_query_string
On Thu, Apr 08, 2021 at 05:46:07PM +0530, Amit Kapila wrote:
>
> @@ -1421,8 +1421,9 @@ ParallelQueryMain(dsm_segment *seg, shm_toc *toc)
> /* Setting debug_query_string for individual workers */
> debug_query_string = queryDesc->sourceText;
>
> - /* Report workers' query for monitoring
On Thu, Apr 8, 2021 at 9:47 AM Julien Rouhaud wrote:
>
> On Wed, Apr 07, 2021 at 02:12:11PM -0400, Bruce Momjian wrote:
> >
> > Patch applied. I am ready to adjust this with any improvements people
> > might have. Thank you for all the good feedback we got on this, and I
> > know many users
On Thu, Apr 08, 2021 at 11:36:48PM +1200, Thomas Munro wrote:
> Hi Julien, Bruce,
>
> A warning appears on 32 bit systems:
>
> In file included from pgstatfuncs.c:15:
> pgstatfuncs.c: In function 'pg_stat_get_activity':
> ../../../../src/include/postgres.h:593:29: warning: cast to pointer
> from
Hi Julien, Bruce,
A warning appears on 32 bit systems:
In file included from pgstatfuncs.c:15:
pgstatfuncs.c: In function 'pg_stat_get_activity':
../../../../src/include/postgres.h:593:29: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
593 | #define
On Wed, Apr 07, 2021 at 02:12:11PM -0400, Bruce Momjian wrote:
>
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
Thanks a lot Bruce and
On 2021-Apr-07, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> > Thanks! And I agree with using query_id in the new field names while
> > keeping
> > queryid for pg_stat_statements to avoid unnecessary query breakage.
>
> I think we need more feedback
On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 10:31:01PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > > Unless I'm missing something this will output the query id in the next
> > > > log
> > > >
On Wed, Apr 07, 2021 at 10:31:01PM -0400, Bruce Momjian wrote:
> On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > Unless I'm missing something this will output the query id in the next log
> > > line? The new code should be added before the newline is output, and the
> > >
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > Unless I'm missing something this will output the query id in the next log
> > line? The new code should be added before the newline is output, and the
> > comma
> > should also be output before the queryid.
>
> Yes, correct,
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > I am also confused about the inconsistency of calling the GUC
> > > compute_query_id (with underscore), but pg_stat_activity.queryid. If we
> > > make it pg_stat_activity.query_id, it doesn't match most of the other
> > > *id
On Thu, Apr 8, 2021 at 08:47:48AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 07:38:35PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Uh, I think your patch missed a few things. First, you use "%zd"
> >
On Wed, Apr 07, 2021 at 07:38:35PM -0400, Bruce Momjian wrote:
> On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Uh, I think your patch missed a few things. First, you use "%zd"
> > > (size_t) for the printf string, but calls to pgstat_get_my_queryid()
On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think your patch missed a few things. First, you use "%zd"
> > (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
> > src/backend/utils/error/elog.c used "%ld". Which is correct? I
Bruce Momjian writes:
> Uh, I think your patch missed a few things. First, you use "%zd"
> (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
> src/backend/utils/error/elog.c used "%ld". Which is correct? I see
> pgstat_get_my_queryid() as returning uint64, but I didn't
On Thu, Apr 8, 2021 at 05:56:25AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 04:22:55PM -0400, Bruce Momjian wrote:
> > aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Patch applied. I am ready to adjust this with any improvements
On Thu, Apr 08, 2021 at 05:56:25AM +0800, Julien Rouhaud wrote:
>
> I also added the queryid to the csvlog output and fixed the documentation that
> mention how to create a table to access the data.
Note that I chose to output a 0 queryid if none has been computed rather that
outputting nothing.
On Wed, Apr 07, 2021 at 04:22:55PM -0400, Bruce Momjian wrote:
> aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Patch applied. I am ready to adjust this with any improvements people
> > > might have. Thank you for all the good feedback we got on this,
aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. I am ready to adjust this with any improvements people
> > might have. Thank you for all the good feedback we got on this, and I
> > know many users have waited a long time for this feature.
>
Bruce Momjian writes:
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
For starters, you could try to make the buildfarm green again.
On Wed, Apr 07, 2021 at 02:12:11PM -0400, Bruce Momjian wrote:
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
If you support
On Wed, Apr 7, 2021 at 08:57:26PM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 06:15:27PM +0530, Nitin Jadhav wrote:
> >
> > I feel we should merge both of the conditions as it is done in
> > pgstat_report_xact_timestamp(). Probably we can write a common comment to
> > explain both the
On Wed, Apr 07, 2021 at 06:15:27PM +0530, Nitin Jadhav wrote:
>
> I feel we should merge both of the conditions as it is done in
> pgstat_report_xact_timestamp(). Probably we can write a common comment to
> explain both the conditions.
>
> [...]
>
> Thanks for the explanation. Please add a
>
> On Tue, Apr 06, 2021 at 11:41:52AM -0400, Alvaro Herrera wrote:
> > On 2021-Apr-06, Nitin Jadhav wrote:
> >
> > > I have reviewed the code. Here are a few minor comments.
> > >
> > > 1.
> > > +void
> > > +pgstat_report_queryid(uint64 queryId, bool force)
> > > +{
> > > + volatile
>
> >
> > 1.
> > +void
> > +pgstat_report_queryid(uint64 queryId, bool force)
> > +{
> > + volatile PgBackendStatus *beentry = MyBEEntry;
> > +
> > + if (!beentry)
> > + return;
> > +
> > + /*
> > + * if track_activities is disabled, st_queryid should already have been
> > + * reset
> > + */
> > +
On Tue, Apr 06, 2021 at 11:41:52AM -0400, Alvaro Herrera wrote:
> On 2021-Apr-06, Nitin Jadhav wrote:
>
> > I have reviewed the code. Here are a few minor comments.
> >
> > 1.
> > +void
> > +pgstat_report_queryid(uint64 queryId, bool force)
> > +{
> > + volatile PgBackendStatus *beentry =
On 2021-Apr-06, Nitin Jadhav wrote:
> I have reviewed the code. Here are a few minor comments.
>
> 1.
> +void
> +pgstat_report_queryid(uint64 queryId, bool force)
> +{
> + volatile PgBackendStatus *beentry = MyBEEntry;
> +
> + if (!beentry)
> + return;
> +
> + /*
> + * if track_activities is
On Tue, Apr 06, 2021 at 08:05:19PM +0530, Nitin Jadhav wrote:
>
> 1.
> +void
> +pgstat_report_queryid(uint64 queryId, bool force)
> +{
> + volatile PgBackendStatus *beentry = MyBEEntry;
> +
> + if (!beentry)
> + return;
> +
> + /*
> + * if track_activities is disabled, st_queryid should already
I have reviewed the code. Here are a few minor comments.
1.
+void
+pgstat_report_queryid(uint64 queryId, bool force)
+{
+ volatile PgBackendStatus *beentry = MyBEEntry;
+
+ if (!beentry)
+ return;
+
+ /*
+ * if track_activities is disabled, st_queryid should already have been
+ * reset
+ */
+ if
On Sun, Apr 4, 2021 at 10:18:50PM +0800, Julien Rouhaud wrote:
> On Fri, Apr 02, 2021 at 01:33:28PM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 01, 2021 at 03:27:11PM -0400, Bruce Momjian wrote:
> > >
> > > OK, I am happy with your design decisions, thanks.
> >
> > Thanks! While double
On Fri, Apr 02, 2021 at 01:33:28PM +0800, Julien Rouhaud wrote:
> On Thu, Apr 01, 2021 at 03:27:11PM -0400, Bruce Momjian wrote:
> >
> > OK, I am happy with your design decisions, thanks.
>
> Thanks! While double checking I noticed that I failed to remove a (now)
> useless include of pgstat.h
On Thu, Apr 01, 2021 at 03:27:11PM -0400, Bruce Momjian wrote:
>
> OK, I am happy with your design decisions, thanks.
Thanks! While double checking I noticed that I failed to remove a (now)
useless include of pgstat.h in nodeGatherMerge.c in last version. I'm
attaching v22 to fix that, no
On Fri, Apr 2, 2021 at 02:28:02AM +0800, Julien Rouhaud wrote:
> Unless I'm missing something query_string isn't a global variable, it's a
> parameter passed to exec_simple_query() from postgresMain().
>
> It's then passed to the stats collector to be able to be displayed in
> pg_stat_activity
On Thu, Apr 01, 2021 at 01:59:15PM -0400, Bruce Momjian wrote:
> On Thu, Apr 1, 2021 at 01:56:42PM -0400, Bruce Momjian wrote:
> > You are using:
> >
> > /* --
> > * pgstat_get_my_queryid() -
> > *
> > * Return current backend's query identifier.
> > */
> >
On Thu, Apr 1, 2021 at 01:56:42PM -0400, Bruce Momjian wrote:
> You are using:
>
> /* --
>* pgstat_get_my_queryid() -
>*
>* Return current backend's query identifier.
>*/
> uint64
> pgstat_get_my_queryid(void)
> {
>
On Thu, Apr 1, 2021 at 11:30:15PM +0800, Julien Rouhaud wrote:
> On Thu, Apr 01, 2021 at 11:05:24PM +0800, Julien Rouhaud wrote:
> > On Wed, Mar 31, 2021 at 11:18:45AM -0300, Alvaro Herrera wrote:
> > > On 2021-Mar-31, Bruce Momjian wrote:
> > > >
> > > > I assume it is since Alvaro didn't
On Thu, Apr 01, 2021 at 11:05:24PM +0800, Julien Rouhaud wrote:
> On Wed, Mar 31, 2021 at 11:18:45AM -0300, Alvaro Herrera wrote:
> > On 2021-Mar-31, Bruce Momjian wrote:
> > >
> > > I assume it is since Alvaro didn't reply. I am planning to apply this
> > > soon.
> >
> > I'm afraid I don't
On Wed, Mar 31, 2021 at 11:18:45AM -0300, Alvaro Herrera wrote:
> On 2021-Mar-31, Bruce Momjian wrote:
> >
> > I assume it is since Alvaro didn't reply. I am planning to apply this
> > soon.
>
> I'm afraid I don't know enough about how parallel query works to make a
> good assessment on this
On 2021-Mar-31, Bruce Momjian wrote:
> On Wed, Mar 31, 2021 at 11:25:32AM +0800, Julien Rouhaud wrote:
> > On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote:
> > > On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote:
> > > > I find it odd that there's executor code that
On Wed, Mar 31, 2021 at 11:25:32AM +0800, Julien Rouhaud wrote:
> On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote:
> > On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote:
> > > On 2021-Mar-24, Julien Rouhaud wrote:
> > >
> > > > From
On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote:
> On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote:
> > On 2021-Mar-24, Julien Rouhaud wrote:
> >
> > > From e08c9d5fc86ba722844d97000798de868890aba3 Mon Sep 17 00:00:00 2001
> > > From: Bruce Momjian
> > > Date: Mon,
On Wed, Mar 24, 2021 at 11:20:49PM +0800, Julien Rouhaud wrote:
> On Wed, Mar 24, 2021 at 08:13:40AM -0400, Bruce Momjian wrote:
> > I have no local modifications. Please modify the patch I posted and
> > repost your version, thanks.
>
> Ok! I used the last version of the patch you sent and
On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote:
> On 2021-Mar-24, Julien Rouhaud wrote:
>
> > From e08c9d5fc86ba722844d97000798de868890aba3 Mon Sep 17 00:00:00 2001
> > From: Bruce Momjian
> > Date: Mon, 22 Mar 2021 17:43:23 -0400
> > Subject: [PATCH v20 2/3] Expose queryid in
On 2021-Mar-24, Julien Rouhaud wrote:
> From e08c9d5fc86ba722844d97000798de868890aba3 Mon Sep 17 00:00:00 2001
> From: Bruce Momjian
> Date: Mon, 22 Mar 2021 17:43:23 -0400
> Subject: [PATCH v20 2/3] Expose queryid in pg_stat_activity and
> src/backend/executor/execMain.c | 9
On Wed, Mar 24, 2021 at 08:13:40AM -0400, Bruce Momjian wrote:
> On Wed, Mar 24, 2021 at 04:51:40PM +0800, Julien Rouhaud wrote:
> > > but if you do that it'd be better to avoid
> > > introducing a function with one name and renaming it in your next
> > > commit.
> >
> > Oops, I apparently messed
On Wed, Mar 24, 2021 at 04:51:40PM +0800, Julien Rouhaud wrote:
> > but if you do that it'd be better to avoid
> > introducing a function with one name and renaming it in your next
> > commit.
>
> Oops, I apparently messed a fixup when working on it. Bruce, should I take
> care of that of do you
On Wed, Mar 24, 2021 at 05:12:35AM -0300, Alvaro Herrera wrote:
> On 2021-Mar-22, Bruce Momjian wrote:
>
> > diff --git a/src/include/catalog/pg_proc.dat
> > b/src/include/catalog/pg_proc.dat
> > index e259531f60..9550de0798 100644
> > --- a/src/include/catalog/pg_proc.dat
> > +++
On 2021-Mar-22, Bruce Momjian wrote:
> diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
> index e259531f60..9550de0798 100644
> --- a/src/include/catalog/pg_proc.dat
> +++ b/src/include/catalog/pg_proc.dat
> @@ -5249,9 +5249,9 @@
>proname =>
On Tue, Mar 23, 2021 at 12:27:10PM -0400, Bruce Momjian wrote:
>
> No, I was thinking of just doing a single commit. Should I do three
> commits? I posted it as three patches since that is how it was posted
> by the author, and reviewing is easier. It also will need a catversion
> bump.
Yes,
On Tue, Mar 23, 2021 at 10:34:38AM -0400, Bruce Momjian wrote:
> On Tue, Mar 23, 2021 at 02:36:27PM +0800, Julien Rouhaud wrote:
> >
> > Is that an oversight in ca3b37487be333a1d241dab1bbdd17a211a88f43, at least
> > for
> > non .po files?
>
> No, I don't think so. We don't change the Free
On Tue, Mar 23, 2021 at 12:12:03PM -0300, Álvaro Herrera wrote:
> On 2021-Mar-22, Bruce Momjian wrote:
>
> > --- a/doc/src/sgml/ref/explain.sgml
> > +++ b/doc/src/sgml/ref/explain.sgml
> > @@ -136,8 +136,10 @@ ROLLBACK;
> >the output column list for each node in the plan tree,
On 2021-Mar-22, Bruce Momjian wrote:
> --- a/doc/src/sgml/ref/explain.sgml
> +++ b/doc/src/sgml/ref/explain.sgml
> @@ -136,8 +136,10 @@ ROLLBACK;
>the output column list for each node in the plan tree, schema-qualify
>table and function names, always label variables in expressions
On Tue, Mar 23, 2021 at 02:36:27PM +0800, Julien Rouhaud wrote:
> On Mon, Mar 22, 2021 at 08:43:40PM -0400, Bruce Momjian wrote:
> > On Mon, Mar 22, 2021 at 05:17:15PM -0700, Zhihong Yu wrote:
> > > Hi,
> > > For queryjumble.c :
> > >
> > > + * Portions Copyright (c) 1996-2020, PostgreSQL Global
On Mon, Mar 22, 2021 at 08:43:40PM -0400, Bruce Momjian wrote:
> On Mon, Mar 22, 2021 at 05:17:15PM -0700, Zhihong Yu wrote:
> > Hi,
> > For queryjumble.c :
> >
> > + * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
> >
> > The year should be updated.
> > Same with
On Mon, Mar 22, 2021 at 05:55:54PM -0400, Bruce Momjian wrote:
>
> OK, after reading the entire thread, I don't think there are any
> remaining open issues with this patch and I think this is ready for
> committing. I have adjusted the doc section of the patches, attached.
> I have marked
On Mon, Mar 22, 2021 at 05:17:15PM -0700, Zhihong Yu wrote:
> Hi,
> For queryjumble.c :
>
> + * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
>
> The year should be updated.
> Same with queryjumble.h
Thanks, fixed.
--
Bruce Momjian https://momjian.us
EDB
Hi,
For queryjumble.c :
+ * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
The year should be updated.
Same with queryjumble.h
Cheers
On Mon, Mar 22, 2021 at 2:56 PM Bruce Momjian wrote:
> On Sat, Mar 20, 2021 at 02:12:34PM +0800, Julien Rouhaud wrote:
> > On Fri, Mar
On Sat, Mar 20, 2021 at 02:12:34PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 19, 2021 at 12:53:18PM -0400, Bruce Momjian wrote:
> >
> > Well, given we don't really want to support multiple query id types
> > being generated or displayed, the "error out" above should fix it.
> >
> > Let's do
It would be really convenient if user-visible serialisations of the query
id had something that identifies the computation method.
maybe prefix 'N' for internal, 'S' for pg_stat_statements etc.
This would immediately show in logs at what point the id calculator was
changed
On Fri, Mar 19, 2021
On Fri, Mar 19, 2021 at 12:53:18PM -0400, Bruce Momjian wrote:
>
> Well, given we don't really want to support multiple query id types
> being generated or displayed, the "error out" above should fix it.
>
> Let's do this --- tell extensions to error out if the query id is
> already set, either
On Fri, Mar 19, 2021 at 08:10:54PM -0400, Bruce Momjian wrote:
> On Sat, Mar 20, 2021 at 01:03:16AM +0100, Hannu Krosing wrote:
> > It would be really convenient if user-visible serialisations of the query id
> > had something that identifies the computation method.
> >
> > maybe prefix 'N' for
On Sat, Mar 20, 2021 at 01:03:16AM +0100, Hannu Krosing wrote:
> It would be really convenient if user-visible serialisations of the query id
> had something that identifies the computation method.
>
> maybe prefix 'N' for internal, 'S' for pg_stat_statements etc.
>
> This would immediately show
On Fri, Mar 19, 2021 at 10:27:51PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote:
> > OK, that makes perfect sense. I think the best solution is to document
> > that compute_query_id just controls the built-in computation of the
> > query id, and
On Fri, Mar 19, 2021 at 10:35:21PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote:
> > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote:
> > The log-spam could be mitigated by logging it just once per connection
> > the first time it is overridden
On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote:
> On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote:
> >
> > OK, that makes perfect sense. I think the best solution is to document
> > that compute_query_id just controls the built-in computation of the
> > query id, and that
On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote:
> On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote:
> > Now that I'm back on the code I remember why I did it this way. It's
> > unfortunately not really possible to make things work this way.
> >
> >
On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote:
>
> OK, that makes perfect sense. I think the best solution is to document
> that compute_query_id just controls the built-in computation of the
> query id, and that extensions can also compute it if this is off, and
> pg_stat_activity and
On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote:
> On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote:
> > On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
> >
> > The above text is the part that made me think an extension could display
> > a query id even
On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote:
> On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
>
> The above text is the part that made me think an extension could display
> a query id even if disabled by the GUC.
With the last version of the patch I sent it was
On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
> On Thu, Mar 18, 2021 at 09:47:29AM -0400, Bruce Momjian wrote:
> > On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote:
> > > Note exactly. Right now a custom queryid can be computed even if
> > > compute_queryid is off,
On Thu, Mar 18, 2021 at 09:47:29AM -0400, Bruce Momjian wrote:
> On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote:
> > On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> > > OK, is that what everyone wants? I think that is what the patch already
> > > does.
> >
> >
On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote:
> On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> > OK, is that what everyone wants? I think that is what the patch already
> > does.
>
> Note exactly. Right now a custom queryid can be computed even if
>
On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> On Wed, Mar 17, 2021 at 04:04:44PM -0400, Robert Haas wrote:
> > On Wed, Mar 17, 2021 at 12:48 PM Julien Rouhaud wrote:
> > > I originally suggested to make it clearer by having an enum GUC rather
> > > than a
> > > boolean, say
On Wed, Mar 17, 2021 at 04:04:44PM -0400, Robert Haas wrote:
> On Wed, Mar 17, 2021 at 12:48 PM Julien Rouhaud wrote:
> > I originally suggested to make it clearer by having an enum GUC rather than
> > a
> > boolean, say compute_queryid = [ none | core | external ], and if set to
> > external
1 - 100 of 220 matches
Mail list logo
