Thread: Easily reading debug_print_plan
Hi all I'm spending a lot of time staring at parse and plan trees at the moment, and I'm finding reading them rather cumbersome. For those of you who do this a lot, do you use any sort of tooling to help you out? Just being able to collapse and expand subtrees would be a lifesaver. If it's a hassle for others too, how would you feel about using json as an output format in future releases? It'd be pretty simple to retrofit by the looks, though updating the regression tests would be a PITA. My main concern would be effects on back-patching. If the conensus opinion on that is "hell no" or if it's a much bigger job than I thought I'll just write a converter that ingests node trees and spits out json I can view using existing tools. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 11/20/2013 09:12 AM, Craig Ringer wrote: > Hi all > > I'm spending a lot of time staring at parse and plan trees at the > moment, and I'm finding reading them rather cumbersome. > > For those of you who do this a lot, do you use any sort of tooling to > help you out? vim editor. The '%' shortcut can be used to jump between opening and closing brackets and thus skip smaller or bigger parts of the output. IMO, this output is primarily for hackers (as opposed to application developers or users) and hacker should know at least a few vim shortcuts anyway :-) // Tony
On 11/20/2013 04:12 PM, Craig Ringer wrote: > Hi all > > I'm spending a lot of time staring at parse and plan trees at the > moment, and I'm finding reading them rather cumbersome. > > For those of you who do this a lot, do you use any sort of tooling to > help you out? Just being able to collapse and expand subtrees would be a > lifesaver. > > If it's a hassle for others too, how would you feel about using json as > an output format in future releases? It'd be pretty simple to retrofit > by the looks, though updating the regression tests would be a PITA. My > main concern would be effects on back-patching. Inevitably, as soon as I post I realise why it's "hell no". The same representation is used for storing rules. So it can't be changed for BC reasons and compactness/performance. I'll just post-process. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 11/20/2013 04:22 PM, Antonin Houska wrote: > vim editor. The '%' shortcut can be used to jump between opening and > closing brackets and thus skip smaller or bigger parts of the output. > IMO, this output is primarily for hackers (as opposed to application > developers or users) and hacker should know at least a few vim shortcuts > anyway :-) That's what I'm currently doing, I just wanted something that makes it quicker and easier. Jumping around the tree is good, but easy collapse/expand would be much better. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Craig Ringer <craig@2ndquadrant.com> writes: > That's what I'm currently doing, I just wanted something that makes it > quicker and easier. Jumping around the tree is good, but easy > collapse/expand would be much better. As I'm using psql under an Emacs M-x shell buffer, I wanted to experiment with your problem here, so that fellow PostgreSQL hackers using Emacs too can benefit already. I'm sure most already have some setup for that, but maybe not. Using the external package hide-region as documented at the following place solved it: http://www.emacswiki.org/emacs/HideRegion Now I can easily collapse and expand regions directly from within the M-x shell psql buffer, no copy paste, no effort needed. When the point is on an opening block { it will do the right thing, if I want to hide something more detailed I can select a region then hide it. Of course using the default following tool makes things really easier as a single key stroke will default to selecting the right region, and another one will expand the selection to the next logical block. C-M-SPC runs the command mark-sexp Oh, and you can define the region using your mouse too. As often, when searching for text based interactive manipulation tooling, the best I could find is the one I'm already using, Emacs ;-) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Craig Ringer <craig@2ndquadrant.com> writes:
> I'm spending a lot of time staring at parse and plan trees at the
> moment, and I'm finding reading them rather cumbersome.
Is there a particular reason you're doing that rather than looking at
EXPLAIN output? Only the latter is meant to be at all user-friendly.
> For those of you who do this a lot, do you use any sort of tooling to
> help you out? Just being able to collapse and expand subtrees would be a
> lifesaver.
vim was mentioned --- I prefer emacs, which can also find the matching
brace pretty easily.
> If it's a hassle for others too, how would you feel about using json as
> an output format in future releases? It'd be pretty simple to retrofit
> by the looks, though updating the regression tests would be a PITA. My
> main concern would be effects on back-patching.
The internal trees appear nowhere in the regression test outputs AFAIK.
> The same representation is used for storing rules. So it can't be
> changed for BC reasons and compactness/performance.
We could in principle change to a different text representation for
stored rules. Compactness would be an issue if it were materially
bigger than the existing formatting, but offhand it seems like JSON
is morally equivalent to what we do now, no?
If you think this is worthwhile, you might care to take a look at
outfuncs.c/readfuncs.c and figure out what it'd take to switch to
json-compatible formatting.
regards, tom lane
On Wed, Nov 20, 2013 at 9:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We could in principle change to a different text representation for
> stored rules. Compactness would be an issue if it were materially
> bigger than the existing formatting, but offhand it seems like JSON
> is morally equivalent to what we do now, no?
Yeah, but it gains a little.
{FROB :zot 3}
would become something like
{"type": "FROB", "zot": 3}
You could minimize the damage by using a single character name, like
an underscore, for the node type, and emitting all whitespace:
{"_":"FROB","zot":3}
...but it's still more. Possibly not enough to matter, but more.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/20/2013 10:36 PM, Tom Lane wrote: > Craig Ringer <craig@2ndquadrant.com> writes: >> I'm spending a lot of time staring at parse and plan trees at the >> moment, and I'm finding reading them rather cumbersome. > > Is there a particular reason you're doing that rather than looking at > EXPLAIN output? Only the latter is meant to be at all user-friendly. Because I'm working on updatable security_barrier views using the approach outlined to the list earlier. EXPLAIN really doesn't do the trick for working on the guts of the rewriter. >> The same representation is used for storing rules. So it can't be >> changed for BC reasons and compactness/performance. > > We could in principle change to a different text representation for > stored rules. Compactness would be an issue if it were materially > bigger than the existing formatting, but offhand it seems like JSON > is morally equivalent to what we do now, no? > > If you think this is worthwhile, you might care to take a look at > outfuncs.c/readfuncs.c and figure out what it'd take to switch to > json-compatible formatting. I do think it might be worthwhile at some point, but once I remembered it was about more than just debug_print_ output - that DB performance is impacted - I realised it was not a topic for a quick and simple change. Benchmarking required, etc. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Craig Ringer escribió: > On 11/20/2013 04:22 PM, Antonin Houska wrote: > > vim editor. The '%' shortcut can be used to jump between opening and > > closing brackets and thus skip smaller or bigger parts of the output. > > IMO, this output is primarily for hackers (as opposed to application > > developers or users) and hacker should know at least a few vim shortcuts > > anyway :-) > > That's what I'm currently doing, I just wanted something that makes it > quicker and easier. Jumping around the tree is good, but easy > collapse/expand would be much better. I think teaching Vim to fold (see ":help foldmethod") using the syntax might be useful. I would assume it's just a matter of writing a syntax colorizer for outfuncs.c output, and set the foldmethod to syntax ...? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services