[bflesch]

I love this tool! But generally speaking, the user experience of the PostgreSQL admin workflow could be improved so much.

The psql client binary should include visualizations like this even in text mode, so admins don't have to follow a multitude of steps as described in the repo:

1) run query, store results in .json file

2) scp .json file to your dev machine

3) run visualization tool

If I already have a psql client shell open, why can't this all be done in the background? I think there is still a lot of potential for improvement.

[mgartner]

If you run the psql client from your dev machine, there’s no need for step 2. Also, in practice I don’t save the output JSON to a file, I just pipe it directly to pg_flame. The README breaks it up into multiple steps, but maybe I could make it clear that it’s not necessary.

But in general I do agree that simplifying this type of tooling is a good thing and something to strive for.

[CodeWriter23]

Impossible with Aurora Serverless. Only VPC IPs can connect.

[davidjnelson]

Would a bastion host help here?

[dbetteridge]

Yes, that's how we do things.

Ssh to 3333:dburl bastionhost -> psql to localhost:3333

[miohtama]

Could the workflow done so that you just copy-paste output from a PSQL shell to an online tool?

[ken]

Had this been implemented as a web service, half of the crowd would be asking for it to be an open-source program, so they could run it locally, for speed and flexibility and security. It was implemented as an open-source program, so half of the crowd are asking for it to be a web service for usability and convenience and aesthetics.

What I'm seeing is we've got two big platforms (web, CLI) and they both have some distinct advantages and some distinct disadvantages, and it's not easy for either one to cross the chasm and compete with the other one directly. We desperately need a new platform which combines what we like about both of these, and discards what we don't.

Until then, we're just going to keep implementing all end-user functionality twice, because by historical accident developers do most of their work in a DEC VT100 emulator, and end-users won't tolerate that.

[Xylakant]

> It was implemented as an open-source program, so half of the crowd are asking for it to be a web service for usability and convenience and aesthetics

I’ll prefer that any time of day. At least, this way someone can easily turn it into a web service. It generates HTML afaics.

[londons_explore]

A good number of github projects I find say "Install with npm install foo, or try it out online [here]"

The online version can host the exact same code from git master. For many projects, no hosting is even required, because the whole thing can run in a codepen-like playground.

[mgartner]

I built it as a CLI because of the reasons you mention, but also because I find that workflow most convenient for me and I didn’t want to need an internet connection.

[bflesch]

Yes, some tools such as the query analyzer by depesz [1] work by copy-pasting the EXPALIN ANALYZE output into your browser.

But IMHO the overall friction is still too large for such a central use case as query optimization done by a database admin.

The PostgreSQL team has been innovating and improving steadily, so I am confident these kind of workflows will be heavily optimized within the next couple of years.

[1] https://explain.depesz.com/

[rc_mob]

Mighty god odin bless you for that link. Thank u so much

[takeda]

that tool is a must if you plan improve, depesz (who is here on HN) also has good blog about postgres, he describes new upcoming features.

He also wrote a blog series about understanding explain plans: https://www.depesz.com/tag/unexplainable/ his explain tool + that information is really good starting point when trying to optimize queries.

[aeyes]

This is the best tool I know, works pasting only the JSON output: http://tatiyants.com/postgres-query-plan-visualization/

The information density the rendering gives me is way better than the flamegraph.

[daamien]

See PEV2 : https://github.com/dalibo/pev2

[hans_castorp]

I never understood the obsession with the graphical display of execution plans (neither in Postgres nor in Oracle).

I find the text output much more useful and detailed then any graphical display. Especially when generated with "explain (analyze, buffers, timing) ..." and "track_io_timing" turned on.

[ldng]

Well different mind work differently. Some are more receptive to visuals. I don't understand why some people refuse to acknowledge that.

[mgartner]

I think the text display is great too! I built pg_flame mostly to help understand the relative timing of each step. Your brain can compare the size of each bar in a flamegraph virtually instantly, while comparing a bunch of actual time numbers scattered throughout the text output takes some time.

tldr; use both as needed