Hi,
I've committed this, with some minor documentation tweaks. I've also
fixed a minor bug in the last patch, where the group with settings was
not properly labeled in some formats (e.g. json).
Thanks to all the reviewers!
regards
--
Tomas Vondra http://www.2ndQuadrant.com
Po
On Fri, 29 Mar 2019 at 22:07, Tomas Vondra
wrote:
> On Wed, Mar 27, 2019 at 09:06:04AM +0100, Rafia Sabih wrote:
> >On Tue, 26 Mar 2019 at 21:04, Tomas Vondra
> >wrote:
> >
> >> On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote:
> >> >On Sun, 24 Feb 2019 at 00:06, Tomas Vondra <
> toma
On Wed, Mar 27, 2019 at 09:06:04AM +0100, Rafia Sabih wrote:
On Tue, 26 Mar 2019 at 21:04, Tomas Vondra
wrote:
On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote:
>On Sun, 24 Feb 2019 at 00:06, Tomas Vondra
wrote:
>>
>> Hi,
>>
>> attached is an updated patch, fixing and slightly twea
On Tue, 26 Mar 2019 at 21:04, Tomas Vondra
wrote:
> On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote:
> >On Sun, 24 Feb 2019 at 00:06, Tomas Vondra
> wrote:
> >>
> >> Hi,
> >>
> >> attached is an updated patch, fixing and slightly tweaking the docs.
> >>
> >>
> >> Barring objections,
On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote:
On Sun, 24 Feb 2019 at 00:06, Tomas Vondra wrote:
Hi,
attached is an updated patch, fixing and slightly tweaking the docs.
Barring objections, I'll get this committed later next week.
I was having a look at this patch, and this
On Sun, 24 Feb 2019 at 00:06, Tomas Vondra wrote:
>
> Hi,
>
> attached is an updated patch, fixing and slightly tweaking the docs.
>
>
> Barring objections, I'll get this committed later next week.
>
I was having a look at this patch, and this kept me wondering,
+static void
+ExplainShowSettings(
Hi,
attached is an updated patch, fixing and slightly tweaking the docs.
Barring objections, I'll get this committed later next week.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From ba0dc2578351e9c3c29cbd00
On 2019-02-15 17:10:28 +0100, Tomas Vondra wrote:
> True. So you agree printing the values as text (as the patch currently
> does) seems enough? I guess I'm fine with that.
I do agree, yes.
On 2/14/19 8:55 PM, Andres Freund wrote:
> Hi,
>
> On 2019-01-15 02:39:49 +0100, Tomas Vondra wrote:
>>
>>
>> On 1/14/19 11:13 PM, Alvaro Herrera wrote:
>>> On 2019-Jan-14, Tomas Vondra wrote:
>>>
The one slightly annoying issue is that currently all the options are
formatted as text,
Hi,
On 2019-01-15 02:39:49 +0100, Tomas Vondra wrote:
>
>
> On 1/14/19 11:13 PM, Alvaro Herrera wrote:
> > On 2019-Jan-14, Tomas Vondra wrote:
> >
> >> The one slightly annoying issue is that currently all the options are
> >> formatted as text, including e.g. cpu_tuple_cost. That's because the
On Tue, Jan 22, 2019 at 02:29:06AM +0100, Tomas Vondra wrote:
> Yes, that's an omission in the docs. Will fix.
Could you fix your patch then? I am moving it to next CF, waiting on
author.
--
Michael
signature.asc
Description: PGP signature
On 1/22/19 1:35 AM, John Naylor wrote:
> On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra
> wrote:
>> Attached is v6 of the patch, adopting "settings" instead of "guc".
>
> Ok, looks good. I tried changing config values with the .conf file,
> alter system, and alter database, and tried a few queri
On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra
wrote:
> Attached is v6 of the patch, adopting "settings" instead of "guc".
Ok, looks good. I tried changing config values with the .conf file,
alter system, and alter database, and tried a few queries with
auto_explain. I made a pass through the confi
Hi John,
On 1/16/19 10:08 PM, John Naylor wrote:
>> [v5]
>
> Hi Tomas,
> Peter suggested upthread to use 'settings' rather than 'gucs' for the
> explain option (and output?), and you seemed to agree. Are you going
> to include that in a future version? Speaking of the output, v5's
> default text
> [v5]
Hi Tomas,
Peter suggested upthread to use 'settings' rather than 'gucs' for the
explain option (and output?), and you seemed to agree. Are you going
to include that in a future version? Speaking of the output, v5's
default text doesn't match that of formatted text ('GUCs' / 'GUC').
On 1/14/19 11:13 PM, Alvaro Herrera wrote:
> On 2019-Jan-14, Tomas Vondra wrote:
>
>> The one slightly annoying issue is that currently all the options are
>> formatted as text, including e.g. cpu_tuple_cost. That's because the GUC
>> options may have show hook, so I can't access the value dire
Tomas Vondra-4 wrote
> Hello Sergei,
>
>> This patch correlates with my proposal
>> "add session information column to pg_stat_statements"
>> https://www.postgresql.org/message-id/3aa097d7-7c47-187b-5913-db8366cd4491%40gmail.com
>> They both address the problem to identify the factors that make
>>
On 2019-Jan-14, Tomas Vondra wrote:
> The one slightly annoying issue is that currently all the options are
> formatted as text, including e.g. cpu_tuple_cost. That's because the GUC
> options may have show hook, so I can't access the value directly (not
> sure if there's an option around it).
I
Hello Sergei,
> This patch correlates with my proposal
> "add session information column to pg_stat_statements"
> https://www.postgresql.org/message-id/3aa097d7-7c47-187b-5913-db8366cd4491%40gmail.com
> They both address the problem to identify the factors that make
> different execution plans fo
Hi,
every now and then I have to investigate an execution plan that is
strange in some way and I can't reproduce the same behavior. Usually
it's simply due to data distribution changing since the problem was
observed (say, after a nightly batch load/update).
In many cases it however may be due t
On 1/2/19 4:20 PM, Peter Eisentraut wrote:
> On 14/12/2018 12:41, Tomas Vondra wrote:
>> 1) names of the options
>>
>> I'm not particularly happy with calling the option "gucs" - it's an
>> acronym and many users have little idea what GUC stands for. So I think
>> a better name would be desirable
On 14/12/2018 12:41, Tomas Vondra wrote:
> 1) names of the options
>
> I'm not particularly happy with calling the option "gucs" - it's an
> acronym and many users have little idea what GUC stands for. So I think
> a better name would be desirable, but I'm not sure what would that be.
> Options? P
út 1. 1. 2019 v 20:11 odesílatel Tomas Vondra
napsal:
>
>
> On 1/1/19 6:48 PM, Pavel Stehule wrote:
> >
> >
> > út 1. 1. 2019 v 18:39 odesílatel Tomas Vondra
> > mailto:tomas.von...@2ndquadrant.com>>
> napsal:
> >
> > Attached is v4, changing how GUCs are picked for inclusion on the
> query
>
On 1/1/19 6:48 PM, Pavel Stehule wrote:
>
>
> út 1. 1. 2019 v 18:39 odesílatel Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> napsal:
>
> Attached is v4, changing how GUCs are picked for inclusion on the query
> plans. Instead of picking the GUCs based on group and/or explicitly
út 1. 1. 2019 v 18:39 odesílatel Tomas Vondra
napsal:
> Attached is v4, changing how GUCs are picked for inclusion on the query
> plans. Instead of picking the GUCs based on group and/or explicitly, a
> new GUC_EXPLAIN flag is used for that.
>
> I went through GUCs defined in guc.c and marked tho
Attached is v4, changing how GUCs are picked for inclusion on the query
plans. Instead of picking the GUCs based on group and/or explicitly, a
new GUC_EXPLAIN flag is used for that.
I went through GUCs defined in guc.c and marked those in QUERY_TUNING*
groups accordingly, with the exception of def
On 12/18/18 12:43 AM, Andres Freund wrote:
> Hi,
>
> On 2018-12-18 00:38:16 +0100, Tomas Vondra wrote:
>> On 12/17/18 11:16 PM, Tom Lane wrote:
>>> Tomas Vondra writes:
Yeah, I've been thinking about that too. Currently it gets filtered out
because it's in the CLIENT_CONN_STATEMENT g
Hi,
On 2018-12-18 00:38:16 +0100, Tomas Vondra wrote:
> On 12/17/18 11:16 PM, Tom Lane wrote:
> > Tomas Vondra writes:
> >> Yeah, I've been thinking about that too. Currently it gets filtered out
> >> because it's in the CLIENT_CONN_STATEMENT group, but the code only
> >> includes QUERY_TUNING_*.
On 12/17/18 11:16 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 12/17/18 10:56 PM, legrand legrand wrote:
>>> what would you think about adding
>>> search_path
>>> to that list ?
>
>> Yeah, I've been thinking about that too. Currently it gets filtered out
>> because it's in the CLIENT_CONN_
Tomas Vondra writes:
> On 12/17/18 10:56 PM, legrand legrand wrote:
>> what would you think about adding
>> search_path
>> to that list ?
> Yeah, I've been thinking about that too. Currently it gets filtered out
> because it's in the CLIENT_CONN_STATEMENT group, but the code only
> includes QUERY
Hi,
On 12/17/18 10:56 PM, legrand legrand wrote:
> what would you think about adding
> search_path
> to that list ?
>
Yeah, I've been thinking about that too. Currently it gets filtered out
because it's in the CLIENT_CONN_STATEMENT group, but the code only
includes QUERY_TUNING_*.
But we do
what would you think about adding
search_path
to that list ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 12/14/18 4:32 PM, Tomas Vondra wrote:
>
>
> On 12/14/18 4:21 PM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> ... I propose to extend EXPLAIN output with an additional option, which
>>> would include information about modified GUCs in the execution plan
>>> (disabled by default, of course):
On 12/14/18 4:21 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> ... I propose to extend EXPLAIN output with an additional option, which
>> would include information about modified GUCs in the execution plan
>> (disabled by default, of course):
>
> I'm a bit suspicious about whether this'll have
Tomas Vondra writes:
> ... I propose to extend EXPLAIN output with an additional option, which
> would include information about modified GUCs in the execution plan
> (disabled by default, of course):
I'm a bit suspicious about whether this'll have any actual value,
if it's disabled by default (w
On 12/14/18 3:01 PM, Tomas Vondra wrote:
> On 12/14/18 2:05 PM, Jim Finnerty wrote:
>> You might want to only include the GUCs that are query tuning parameters,
>> i.e., those returned by:
>>
>> SELECT name, setting, category
>> FROM pg_settings
>> WHERE category LIKE 'Query Tuning%'
>> ORDER BY
On 12/14/18 2:05 PM, Jim Finnerty wrote:
> You might want to only include the GUCs that are query tuning parameters,
> i.e., those returned by:
>
> SELECT name, setting, category
> FROM pg_settings
> WHERE category LIKE 'Query Tuning%'
> ORDER BY category, name;
>
Good idea! Thanks.
regards
--
pá 14. 12. 2018 v 12:41 odesílatel Tomas Vondra <
tomas.von...@2ndquadrant.com> napsal:
> Hi,
>
> every now and then I have to investigate an execution plan that is
> strange in some way and I can't reproduce the same behavior. Usually
> it's simply due to data distribution changing since the prob
Hi,
every now and then I have to investigate an execution plan that is
strange in some way and I can't reproduce the same behavior. Usually
it's simply due to data distribution changing since the problem was
observed (say, after a nightly batch load/update).
In many cases it however may be due to
39 matches
Mail list logo
