On Fri, Jun 28, 2019 at 4:39 PM Julien Rouhaud wrote:
>
> On Tue, Mar 19, 2019 at 3:51 PM Julien Rouhaud wrote:
> >
> > On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote:
> > >
> > > On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
> > > >
> > > > Let's take one step back. Since queryId is
On Tue, Mar 19, 2019 at 3:51 PM Julien Rouhaud wrote:
>
> On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote:
> >
> > On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
> > >
> > > Let's take one step back. Since queryId is stored in core as Julien
> > > pointed out, can we just add that global
>> Shoudn't you add this to commitfest ?
> I added it last week, see https://commitfest.postgresql.org/23/2069/
Oups, sorry for the noise
>> Would it make sense to add it in auto explain ?
>> I don't know for explain itself, but maybe ...
> I'd think that people interested in getting the queryid in the logs
> would configure the log_line_prefix to display it consistently rather
> than having it in only a subset of cases, so that's
On Mon, Mar 25, 2019 at 12:36 PM legrand legrand
wrote:
>
> >> Would it make sense to add it in auto explain ?
> >> I don't know for explain itself, but maybe ...
>
> > I'd think that people interested in getting the queryid in the logs
> > would configure the log_line_prefix to display it
Hi Jim, Robert,
As this is a distinct subject from adding QueryId to pg_stat_activity,
would it be possible to continue the discussion "new QueryId definition"
(for postgres open source software) here:
https://www.postgresql.org/message-id/1553029215728-0.p...@n3.nabble.com
Thanks in advance.
On Tue, Mar 19, 2019 at 8:38 PM legrand legrand
wrote:
>
> Would it make sense to add it in auto explain ?
> I don't know for explain itself, but maybe ...
I'd think that people interested in getting the queryid in the logs
would configure the log_line_prefix to display it consistently rather
Great,
thank you Julien !
Would it make sense to add it in auto explain ?
I don't know for explain itself, but maybe ...
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Tue, Mar 19, 2019 at 1:24 PM Jim Finnerty wrote:
> The queryId depends on oids, so it is not stable enough for some purposes.
> For example, to create a SQL identifier that survives across a server
> upgrade, or that can be shipped to another database, the queryId isn't
> usable.
>
> The
On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote:
>
> On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
> >
> > Let's take one step back. Since queryId is stored in core as Julien pointed
> > out, can we just add that global to the pg_stat_get_activity and ultimately
> > exposed in
On Tue, Mar 19, 2019 at 2:45 PM Maksim Milyutin wrote:
>
> But I think that enough to integrate into core the query normalization
> routine and store generalized query strings (from which the queryId is
> produced) in shared memory (for example, hashtable that maps queryId to
> the text
On 3/16/19 5:32 PM, Robert Haas wrote:
There's only one query ID field available, and
you can't use two extensions that care about query ID unless they
compute it the same way, and replicating all the code that computes
the query ID into each new extension that wants one sucks. I think we
On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
>
> Let's take one step back. Since queryId is stored in core as Julien pointed
> out, can we just add that global to the pg_stat_get_activity and ultimately
> exposed in pg_stat_activity view? Then no matter whether PGSS is on or off,
> or
Hello
On Sat, Mar 16, 2019 at 7:32 AM Robert Haas wrote:
> Also, I think this is now the third independent request to expose
> query ID in pg_stat_statements. I think we should give the people
> what they want.
>
Count me as the 4th.
This would be a very important feature for automated query
Thanks a lot for really good points!! I did not expected I will get this
many points of view. :P
I have identical experience with Robert when other extension calculate the
id different as PGSS, PGSS will overwritten that id when it is on. But Tom
got a point that if we centralize the logic that
Hello,
This is available in https://github.com/legrandlegrand/pg_stat_sql_plans
extension with a specific function
pgssp_backend_queryid(pid) that permits to join pg_stat_activity with
pg_stat_sql_plans (that is similar to pg_stat_statements) and also permits
to collect samples of wait events per
On Sat, Mar 16, 2019 at 5:20 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, Mar 15, 2019 at 9:50 PM Tom Lane wrote:
> >> pg_stat_statements has a notion of query ID, but that notion might be
> >> quite inappropriate for other usages, which is why it's an extension
> >> and not core.
>
>
Robert Haas writes:
> On Fri, Mar 15, 2019 at 9:50 PM Tom Lane wrote:
>> pg_stat_statements has a notion of query ID, but that notion might be
>> quite inappropriate for other usages, which is why it's an extension
>> and not core.
> Having written an extension that also wanted a query ID, I
On Fri, Mar 15, 2019 at 9:50 PM Tom Lane wrote:
> Yun Li writes:
> > Do you think if we can add queryId into the pg_stat_get_activity function
> > and ultimatly expose it in the view? It would be easier to track "similar"
> > query's performance over time easier.
>
> No, we're not likely to do
Yun Li writes:
> Do you think if we can add queryId into the pg_stat_get_activity function
> and ultimatly expose it in the view? It would be easier to track "similar"
> query's performance over time easier.
No, we're not likely to do that, because it would mean (1) baking one
single definition
Hey pg developers,
Do you think if we can add queryId into the pg_stat_get_activity function
and ultimatly expose it in the view? It would be easier to track "similar"
query's performance over time easier.
Thanks a lot!
Yun
201 - 221 of 221 matches
Mail list logo
