On Tue, Jul 02, 2019 at 03:06:52PM +0100, Peter Eisentraut wrote:
> On 2019-05-18 19:39, David Fetter wrote:
> > On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> >> David Fetter writes:
> >>> I hope the patch is a little easier to digest as now attached.
> >>
> >> To be blunt, I find 50
On 2019-05-18 19:39, David Fetter wrote:
> On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
>> David Fetter writes:
>>> I hope the patch is a little easier to digest as now attached.
>>
>> To be blunt, I find 500K worth of changes in the regression test
>> outputs to be absolutely unaccep
On Wed, Jun 19, 2019 at 02:08:21PM +0200, Daniel Gustafsson wrote:
> > On 19 Jun 2019, at 08:15, Peter Eisentraut
> > wrote:
> >
> > On 2019-06-18 23:15, David Fetter wrote:
> >> Are you proposing something along the lines of this?
> >>
> >> PROFILE [statement]; /* Shows the plan */
> >> PROFIL
> On 19 Jun 2019, at 08:15, Peter Eisentraut
> wrote:
>
> On 2019-06-18 23:15, David Fetter wrote:
>> Are you proposing something along the lines of this?
>>
>> PROFILE [statement]; /* Shows the plan */
>> PROFILE RUN [statement]; /* Actually executes the query */
>
> No, it would be
>
> EXPL
On 19/06/2019 18:15, Peter Eisentraut wrote:
On 2019-06-18 23:15, David Fetter wrote:
Are you proposing something along the lines of this?
PROFILE [statement]; /* Shows the plan */
PROFILE RUN [statement]; /* Actually executes the query */
No, it would be
EXPLAIN statement; /* Shows the plan
On 2019-06-18 23:15, David Fetter wrote:
> Are you proposing something along the lines of this?
>
> PROFILE [statement]; /* Shows the plan */
> PROFILE RUN [statement]; /* Actually executes the query */
No, it would be
EXPLAIN statement; /* Shows the plan */
PROFILE statement; /* Actually execut
On Tue, Jun 18, 2019 at 11:08:31PM +0200, Peter Eisentraut wrote:
> On 2019-05-15 19:58, Andres Freund wrote:
> > On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> >> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> >> we should probably just drop the whole idea. It seemed li
On 2019-05-15 19:58, Andres Freund wrote:
> On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
>> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
>> we should probably just drop the whole idea. It seemed like a great
>> idea at the time, but it's going to confuse people not just
Andres Freund writes:
> On 2019-05-21 19:38:57 +0200, David Fetter wrote:
>> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
>>> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
>> Would this be worth back-patching? I ask because adding it will cause
>> fairly large
Hi,
On 2019-05-21 19:38:57 +0200, David Fetter wrote:
> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
> > Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
>
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn
On Tue, May 21, 2019 at 1:38 PM David Fetter wrote:
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn in the regression tests.
No. I can't believe you're even asking that question.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
David Fetter writes:
> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
>> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn in the regression tests.
It really
On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
> On Wed, May 15, 2019 at 1:53 PM Tom Lane wrote:
> > >> That seems too confusing.
> >
> > > Ok. Are you voting for using EXEC as a keyword to replace ANALYZE?
> >
> > FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name
On Wed, May 15, 2019 at 1:53 PM Tom Lane wrote:
> >> That seems too confusing.
>
> > Ok. Are you voting for using EXEC as a keyword to replace ANALYZE?
>
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea. It seemed like a great
On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I hope the patch is a little easier to digest as now attached.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when said changes
> are basi
On Wed, May 15, 2019 at 10:46:39AM -0400, Tom Lane wrote:
> Andres Freund writes:
>> On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>>> Indeed. I think we should move our regression tests to TAP and
>>> dispense with this.
>
>> -inconceivably much
>
> Yeah, that's not happening.
+1 to the
Hi,
On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea. It seemed like a great
> idea at the time, but it's going to confuse people not just Bison.
I'm not particularly invested in t
Alvaro Herrera writes:
> On 2019-May-15, Andres Freund wrote:
>> On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
>>> After eyeballing the giant patch set you sent[1], I think EXEC is a
>>> horrible keyword to use -- IMO it should either be the complete word
>>> EXECUTE, or we should pick some
Hello,
On 2019-May-15, Andres Freund wrote:
> On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
> > After eyeballing the giant patch set you sent[1], I think EXEC is a
> > horrible keyword to use -- IMO it should either be the complete word
> > EXECUTE, or we should pick some other word. I rea
Hi,
On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
> After eyeballing the giant patch set you sent[1], I think EXEC is a
> horrible keyword to use -- IMO it should either be the complete word
> EXECUTE, or we should pick some other word. I realize that we do not
> want to have different sets
On 2019-May-13, David Fetter wrote:
> I tried changing it to EXEC (EXPLAIN EXECUTE is already a thing), but
> got a giant flock of reduce-reduce conflicts along with a few
> shift-reduce conflicts.
After eyeballing the giant patch set you sent[1], I think EXEC is a
horrible keyword to use -- IMO
Andres Freund writes:
> On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>> Indeed. I think we should move our regression tests to TAP and
>> dispense with this.
> -inconceivably much
Yeah, that's not happening.
Just eyeing the patch again, it seems like most of the test-output churn
is fro
Hi,
On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
>> David Fetter writes:
>> > I hope the patch is a little easier to digest as now attached.
>>
>> To be blunt, I find 500K worth of changes in the regression test
>> outputs to be
On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I hope the patch is a little easier to digest as now attached.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when said changes
> are basi
David Fetter writes:
> I hope the patch is a little easier to digest as now attached.
To be blunt, I find 500K worth of changes in the regression test
outputs to be absolutely unacceptable, especially when said changes
are basically worthless from a diagnostic standpoint. There are
at least two
On Tue, May 07, 2019 at 06:25:12PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the output in JSON, then we r
> On May 8, 2019, at 4:22 PM, Vik Fearing wrote:
>
> On 07/05/2019 09:30, David Fetter wrote:
>> Folks,
>>
>> It can get a little tedious turning on (or off) all the boolean
>> options to EXPLAIN, so please find attached a shortcut.
>
> I would rather have a set of gucs such as default_explain
On 07/05/2019 09:30, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
I would rather have a set of gucs such as default_explain_buffers,
default_explain_summary, and default_explain_format.
On Tue, May 7, 2019 at 12:31 PM David Fetter wrote:
> If you're tuning a query interactively, it's a lot simpler to prepend,
> for example,
>
> EXPLAIN (ALL, FORMAT JSON)
>
> to it than to prepend something along the lines of
>
> EXPLAIN(ANALYZE, VERBOSE, COSTS, BUFFERS, SETTINGS, TIMING,
On Tue, May 7, 2019 at 6:25 PM Tom Lane wrote:
> Meh --- I don't especially care for non-orthogonal behaviors like that.
> If you wanted JSON but *not* all of the additional info, how would you
> specify that? (The implementation I had in mind would make VERBOSE OFF
> more or less a no-op, so tha
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the output in JSON, then we really
>
Greetings,
* David Fetter (da...@fetter.org) wrote:
> On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > One idea that comes to mind is that VERBOSE could be redefined as
> > > some sort of package of primitive options, including all of
On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >
> > One idea that comes to mind is that VERBOSE could be redefined as
> > some sort of package of primitive options, including all of the
> > "additional information" options
Stephen Frost writes:
> I'm generally in favor of doing something like what Tom is suggesting
> with VERBOSE, but I also feel like it should be the default for formats
> like JSON. If you're asking for the output in JSON, then we really
> should include everything that a flag like VERBOSE would c
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > As I said, I don't think ALL is a good idea under any name. Like it
> > just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> > SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> > s
Andres Freund writes:
> As I said, I don't think ALL is a good idea under any name. Like it
> just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> several separate axis (query is executed or not (ANALYZE), ver
Hi,
On 2019-05-07 23:23:55 +0200, David Fetter wrote:
> Would you agree that there's a problem here as I described as
> motivation for people who operate databases?
Yea, but I don't think the solution is where you seek it. I think the
problem is that our defaults for EXPLAIN, in particular EXPLA
On Tue, May 7, 2019 at 9:31 AM David Fetter wrote:
> If you're tuning a query interactively, it's a lot simpler to prepend,
> for example,
>
> EXPLAIN (ALL, FORMAT JSON)
>
> to it than to prepend something along the lines of
>
> EXPLAIN(ANALYZE, VERBOSE, COSTS, BUFFERS, SETTINGS, TIMING, S
On Tue, May 07, 2019 at 09:44:30AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> > On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > > It can get a little tedious turning on (or o
Hi,
On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > It can get a little tedious turning on (or off) all the boolean
> > > options to EXPLAIN, so please find attached a sho
On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I'm not convinced this is a good idea - it
On Tue, May 07, 2019 at 11:03:23AM +0200, Rafia Sabih wrote:
> On Tue, 7 May 2019 at 09:30, David Fetter wrote:
> >
> > Folks,
> >
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I don't understand this, do you mi
On Tue, May 07, 2019 at 11:13:15AM +0300, Sergei Kornilov wrote:
> Hi
>
> I liked this idea.
>
> + timing_set = true;
> + es->timing = defGetBoolean(opt);
> + summary_set = true;
> + es->timing = defGetBoolean(opt);
>
Hi,
On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
I'm not convinced this is a good idea - it seems likely that we'll add
conflicting options at some point, and then this
On Tue, 7 May 2019 at 09:30, David Fetter wrote:
>
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
I don't understand this, do you mind explaining a bit may be with an
example on how you want it to work.
--
Hi
I liked this idea.
+ timing_set = true;
+ es->timing = defGetBoolean(opt);
+ summary_set = true;
+ es->timing = defGetBoolean(opt);
second es->timing should be es->summary, right?
regards, Sergei
On Tue, May 07, 2019 at 09:30:47AM +0200, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
> Best,
> David.
It helps to have a working patch for this.
Best,
David.
--
David Fetter http:
Folks,
It can get a little tedious turning on (or off) all the boolean
options to EXPLAIN, so please find attached a shortcut.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 8d
48 matches
Mail list logo
