Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
1–10 of 46 posts
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#2I 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.
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#3MySQL (regular and NDB Cluster versions) has "show profile" built-in. It's not graphical, but has similar details. Love it!
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#4I 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…
Could the workflow done so that you just copy-paste output from a PSQL shell to an online tool?
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#5I 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…
Could the workflow done so that you just copy-paste output from a PSQL shell to an online tool?
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.
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#6I 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…
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.
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#7I 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…
Could the workflow done so that you just copy-paste output from a PSQL shell to an online tool?
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.
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#8Earlier quoted context omitted.
Could the workflow done so that you just copy-paste output from a PSQL shell to an online tool?
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 di…
> 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.
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#9I thought this was going to be a tool that automatically has Paul graham flame you lol
Re: Show HN: pg_flame – flamegraph visualizations of PostgreSQL query plans
#10I don't like the way postgres doesn't have the ability to switch query plans mid query.
Frequently a query plan turns out to perform nowhere near as well as the planner expects (for example, because the data distribution is poor, or a key being filtered for doesn't exist). In those cases, flipping the query plan around could turn a 1 hour query into a 1 millisecond query. Yet postgres doesn't have the ability to do that.
Sure a human can sometimes use domain knowledge to sometimes be able to rearrange the query to force a plan that works well, but in the general case, the database shouldn't have performance drop by a factor of 1 million because of semi-arbitrary planner decisions. Being able to try multiple possible plans would be a massive start in solving the issue.