> On 2 Aug 2020, at 00:12, Justin Pryzby wrote:
> On Sun, Aug 02, 2020 at 12:00:56AM +0200, Daniel Gustafsson wrote:
>> My reading of this thread and the above that the patch, and CF entry, as it
>> stands should be rejected - but that a separate patch for turning BUFFERS on
>> by
>> default wou
On Sun, Aug 02, 2020 at 12:00:56AM +0200, Daniel Gustafsson wrote:
> > On 10 Jul 2020, at 15:30, Peter Eisentraut
> > wrote:
> >
> > On 2020-05-23 11:14, Vik Fearing wrote:
> >> Here is a patch to provide default gucs for EXPLAIN options.
> >> I hav
> On 10 Jul 2020, at 15:30, Peter Eisentraut
> wrote:
>
> On 2020-05-23 11:14, Vik Fearing wrote:
>> Here is a patch to provide default gucs for EXPLAIN options.
>> I have two goals with this patch. The first is that I personally
>> *always* want BUFFERS turned on
On 2020-05-23 11:14, Vik Fearing wrote:
Here is a patch to provide default gucs for EXPLAIN options.
I have two goals with this patch. The first is that I personally
*always* want BUFFERS turned on, so this would allow me to do it without
typing it every time.
There was a lot of opposition
I think this got ample review, so I've set it to "Waiting".
--
Justin
Le mer. 3 juin 2020 à 04:16, David Fetter a écrit :
> On Tue, Jun 02, 2020 at 09:28:48PM +0200, Vik Fearing wrote:
> > On 6/2/20 7:54 PM, David G. Johnston wrote:
> > > At this point, given the original goal of the patch was to try and
> > > grease a smoother path to changing the default for BUFF
On Tue, Jun 02, 2020 at 09:28:48PM +0200, Vik Fearing wrote:
> On 6/2/20 7:54 PM, David G. Johnston wrote:
> > At this point, given the original goal of the patch was to try and
> > grease a smoother path to changing the default for BUFFERS, and
> > that people seem OK with doing just that without
On Tue, Jun 2, 2020 at 11:58:51PM +0200, Vik Fearing wrote:
> On 6/2/20 10:51 PM, Bruce Momjian wrote:
> > On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
> >> On 6/2/20 7:25 PM, Bruce Momjian wrote:
> >>> I think it would have been helpful if an email explaining this idea for
> >>> d
On 6/2/20 10:51 PM, Bruce Momjian wrote:
> On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
>> On 6/2/20 7:25 PM, Bruce Momjian wrote:
>>> I think it would have been helpful if an email explaining this idea for
>>> discussion would have been posted before a patch was generated and
>>> p
On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
> On 6/2/20 7:25 PM, Bruce Momjian wrote:
> > On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> >> On 5/27/20 7:27 AM, David G. Johnston wrote:
> Would you propose we just error out in that case, or should we
> sile
On 6/2/20 7:25 PM, Bruce Momjian wrote:
> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
>> On 5/27/20 7:27 AM, David G. Johnston wrote:
Would you propose we just error out in that case, or should we
silently enable the required option, or disable the conflicting
option
On 6/2/20 7:54 PM, David G. Johnston wrote:
> At this point, given the original goal of the patch was to try and grease a
> smoother path to changing the default for BUFFERS, and that people seem OK
> with doing just that without having this patch, I'd say we should just
> change the default and fo
On Tue, Jun 2, 2020 at 10:25 AM Bruce Momjian wrote:
> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> > On 5/27/20 7:27 AM, David G. Johnston wrote:
> > >> Would you propose we just error out in that case, or should we
> > >> silently enable the required option, or disable the con
On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> On 5/27/20 7:27 AM, David G. Johnston wrote:
> >> Would you propose we just error out in that case, or should we
> >> silently enable the required option, or disable the conflicting
> >> option?
> >>
> > The same thing we do today...ign
On Tue, May 26, 2020 at 02:49:46AM +, Nikolay Samokhvalov wrote:
> On Mon, May 25, 2020 at 6:36 PM, Bruce Momjian < br...@momjian.us > wrote:
> > I am not excited about this new feature. Why do it only for
> > EXPLAIN? That is a log of GUCs. I can see this becoming a feature
> > creep disaster.
On Tue, May 26, 2020 at 7:30 AM David Rowley wrote:
> I'm against adding GUCs to control what EXPLAIN does by default.
>
> A few current GUCs come to mind which gives external control to a
> command's behaviour are:
>
> standard_conforming_strings
> backslash_quote
> bytea_output
>
> It's pretty d
On 5/27/20 7:27 AM, David G. Johnston wrote:
> On Tuesday, May 26, 2020, David Rowley wrote:
>
>> On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
>>> Are you saying we should have all new EXPLAIN options off forever into
>>> the future because apps won't know about the new data? I guess we
>>>
On Tuesday, May 26, 2020, David Rowley wrote:
> On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
> > Are you saying we should have all new EXPLAIN options off forever into
> > the future because apps won't know about the new data? I guess we
> > should also not ever introduce new plan nodes bec
On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
> Are you saying we should have all new EXPLAIN options off forever into
> the future because apps won't know about the new data? I guess we
> should also not ever introduce new plan nodes because those won't be
> known either.
Another argument ag
On Tue, May 26, 2020 at 4:53 PM David Rowley wrote:
> If we add
> a new executor node then that's something that the server will send to
> the client. The client does not need knowledge about which version of
> PostreSQL it is connected to. If it receives details about some new
> node type in an
On Tue, May 26, 2020 at 4:30 AM David Rowley wrote:
>
> I imagine the
> authors of those applications might get upset if we create something
> outside of the command that controls what the command does. Perhaps
> the idea here is not quite as bad as that as applications could still
> override the
On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
>
> On 5/26/20 1:30 PM, David Rowley wrote:
> > On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote:
> >>
> >> On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote:
> >>> This is a very good improvement! Using information about buffers
On 5/26/20 10:08 PM, Justin Pryzby wrote:
> If you want to change the default, I think that should be a separate
> patch/thread.
Yes, it will be.
--
Vik Fearing
On Sat, May 23, 2020 at 06:33:48PM +0200, Vik Fearing wrote:
> > Do we really want default_explain_analyze ?
> > It sounds like bad news that EXPLAIN DELETE might or might not remove rows
> > depending on the state of a variable.
>
> I have had sessions where not using ANALYZE was the exception, n
Le mar. 26 mai 2020 à 16:25, Stephen Frost a écrit :
> Greetings,
>
> * Guillaume Lelarge (guilla...@lelarge.info) wrote:
> > Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit
> :
> > > To that end- what if this was done client-side with '\explain' or
> > > similar? Basically, it'd work like \
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> the partial solution can be custom psql statements. Now, it can be just
> workaround
>
> \set explain 'explain (analyze, buffers)'
> :explain select * from pg_class ;
>
> and anybody can prepare customized statements how he likes
Yea
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Monday, May 25, 2020, Stephen Frost wrote:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > > I am not excited about this new feature. Why do it on
Greetings,
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
> Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit :
> > To that end- what if this was done client-side with '\explain' or
> > similar? Basically, it'd work like \watch or \g but we'd have options
> > under pset like "explain_analy
út 26. 5. 2020 v 4:27 odesílatel Stephen Frost napsal:
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > I am not excited about this new feature. Why do it only for EXPLAIN?
>
> Would probably help to understa
On 5/26/20 1:30 PM, David Rowley wrote:
> On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote:
>>
>> On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote:
>>> This is a very good improvement! Using information about buffers is my
>>> favorite
>>> way to optimize queries.
>>>
>>> Not
On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote:
>
> On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote:
> > This is a very good improvement! Using information about buffers is my
> > favorite
> > way to optimize queries.
> >
> > Not having BUFFERS enabled by default means that
On Monday, May 25, 2020, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > I am not excited about this new feature. Why do it only for EXPLAIN?
>
> Would probably help to understand what y
On Saturday, May 23, 2020, Vik Fearing wrote:
>
>
> > Do we really want default_explain_analyze ?
> > It sounds like bad news that EXPLAIN DELETE might or might not remove
> rows
> > depending on the state of a variable.
>
> I have had sessions where not using ANALYZE was the exception, not the
>
Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit :
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > I am not excited about this new feature. Why do it only for EXPLAIN?
>
> Would probably help to understand
On Tue, 2020-05-26 at 02:49 +, Nikolay Samokhvalov wrote:
> > I am not excited about this new feature. Why do it only for EXPLAIN? That
> > is a log of GUCs. I can see this becoming a feature creep disaster.
> >
>
> How about changing the default behavior, making BUFFERS enabled by default?
On Mon, May 25, 2020 at 6:36 PM, Bruce Momjian < br...@momjian.us > wrote:
>
>
>
> I am not excited about this new feature. Why do it only for EXPLAIN? That
> is a log of GUCs. I can see this becoming a feature creep disaster.
>
>
>
>
How about changing the default behavior, making BUFFERS
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > I am not excited about this new feature. Why do it only for EXPLAIN?
Would probably help to understand what your thinking is here regarding
how it could be done for eve
On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> I am not excited about this new feature. Why do it only for EXPLAIN?
> That is a log of GUCs. I can see this becoming a feature creep
> disaster.
FWIW, Neither am I. This would create an extra maintenance cost, and
I would not wa
On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote:
> This is a very good improvement! Using information about buffers is my
> favorite
> way to optimize queries.
>
> Not having BUFFERS enabled by default means that in most cases, when asking
> for
> help, people send execution
Why not allowing the following:
EXPLAIN [ ANALYZE ] [ VERBOSE ] [ ( option [, ...] ) ] statement
That has nothing to do with this patch.
Sure, it was just in passing, I was surprised by this restriction.
--
Fabien.
On 5/24/20 9:31 AM, Fabien COELHO wrote:
> While testing the issue, I'm surprised at the syntax:
>
> EXPLAIN [ ( option [, ...] ) ] statement
> EXPLAIN [ ANALYZE ] [ VERBOSE ] statement
>
> Why not allowing the following:
>
> EXPLAIN [ ANALYZE ] [ VERBOSE ] [ ( option [, ...] ) ] statement
T
The safe option seems not allowing to change ANALYZE option default.
EXPLAIN [ ANALYZE ] [ VERBOSE ] statement
Some more thoughts:
An argument for keeping it that way is that there is already a special
syntax to enable ANALYSE explicitely, which as far as I am concerned I
only ever atte
Bonjour Vik,
Do we really want default_explain_analyze ?
It sounds like bad news that EXPLAIN DELETE might or might not remove rows
depending on the state of a variable.
I have had sessions where not using ANALYZE was the exception, not the
rule. I would much prefer to type EXPLAIN (ANALYZE
t;(ANALYZE, BUFFERS)" all the time.
So I strongly support this change, thank you, Vik.
On Sat, May 23 2020 at 02:14, Vik Fearing < v...@postgresfriends.org > wrote:
>
>
>
> Here is a patch to provide default gucs for EXPLAIN options.
>
>
>
> I have two goals wi
On 5/23/20 6:23 PM, Pavel Stehule wrote:
> It's lot of new GUC variables. Isn't better only one that allows list of
> values?
I like this way better.
--
Vik Fearing
On 5/23/20 6:12 PM, Justin Pryzby wrote:
> The patch adds new GUCs for each explain() option.
Thank you for looking at it!
> Would it be better to make a GUC called default_explain_options which might
> say
> "COSTS ON, ANALYZE ON, VERBOSE OFF, BUFFERS TBD, FORMAT TEXT, ..."
> ..and parsed usin
so 23. 5. 2020 v 11:14 odesílatel Vik Fearing
napsal:
> Here is a patch to provide default gucs for EXPLAIN options.
>
> I have two goals with this patch. The first is that I personally
> *always* want BUFFERS turned on, so this would allow me to do it without
> typing it ever
On Sat, May 23, 2020 at 11:14:05AM +0200, Vik Fearing wrote:
> Here is a patch to provide default gucs for EXPLAIN options.
>
> I have two goals with this patch. The first is that I personally
> *always* want BUFFERS turned on, so this would allow me to do it without
> typin
Here is a patch to provide default gucs for EXPLAIN options.
I have two goals with this patch. The first is that I personally
*always* want BUFFERS turned on, so this would allow me to do it without
typing it every time.
The second is it would make it easier to change the actual default for
49 matches
Mail list logo
