Add some explanation of the *technical* differences between the "DB Type" options

[hi2u]

I really love the idea of your tool, thanks for making it! @le0pard

However every time I've come back to use it over the years (quite a few times), I've found that I really have no idea exactly what kind of differences the "DB Type" setting is going to make, i.e. the options:

• Web application
• Online transaction processing systems
• Data warehouses
• Desktop applications
• Mixed type of applications

Obviously some of them kind of give some hints, e.g. I'm guessing that "Web application" + "Online transaction processing systems" would be aimed more at handling lots of small queries at once, at least compared to "Data warehouses" ... but beyond that I don't know what the difference between "Web application" vs "Online transaction processing systems" would be. Most "Online transaction processing systems" are e-commerce stores, which means that they're also a "Web application".

And while we all know what each of these options "are", that doesn't necessarily correlate to every project in that category (even if our system is simple enough to obviously fit into one of those categories). Often metrics in terms of size/frequency are what are important here, more so that some neat simple business categories based on lots of assumptions.

"Desktop applications" is one where I can't even guess what that will prioritise at all?

• Is it for single-user desktop apps (only one client), or multi-user ones?
• If it's single-user, how is it any different to "Online transaction" or "Data warehouses"?
• If it's multi-user... how is that any different from "Web Application" from postgres's perspective?

For most of my big projects where I even need to bother thinking about changing default postgres settings, they don't even really neatly fall into one of these categories. They're usually a crossover between the first 3. But that doesn't mean that "Mixed" is going to solve any problems for me, there very likely is a more specific option that best fits my project, but I don't know which one it is.

I know what my technical requirements are (2) below, e.g. things like how many users are like to query at once (and who to prioritise)... big vs small queries... lots of JOINs vs not many, reads vs write priority etc... but I have no idea which "DB Type" is going to be most relevant to my technical requirements.

Author vs user perspective

To put it all another way, think about the differences in understanding for you as the author of this tool, vs the users using it...

For you: @le0pard

To build this tool, you've had to think about this in 3 stages:

1. What postgres settings can be changed, e.g. the names of the settings
2. How those settings affect performance of different types of queries / project priorities - i.e the technical stuff like: big vs small queries... lots of JOINs vs not many, reads vs write priority etc
3. And then which "DB Type" you'll box all the facets of (2) into (using a number of assumptions that are opaque to users)

The users of the tool:

Having (3) there is very nice (and is all that some users need), and of course it should remain... but considering you've had to figure out part (2) above... why keep it a secret?

For a lot of us, we're coming at this from having some specific technical requirements re (2) above. We have to try to guess / use the tool in this order...

• From our requirements (2), make a guess at which (3) it would be (which involves many assumptions that might be irrelevant)
• Use the tool as-is to get the answer: (3) -> (1)
• Go and look up the (1) results to see if they're relevant to our project or not (based on all the assumptions we needed to make)
• If not, try again with a different (3)

I've found that any time I've used the tool, I've had to re-generate the configs for all the different type options, which involves doing all the steps above again for each option by trial-and-error.

So keeping in mind that the goal of this tool is to save time for people who don't already have a very good understanding of (1), it's actually making the tool much less useful to us when we're trying to solve issues from the (2) perspective.

For anyone who is actually already having performance issues they need to solve, they're coming at this from (2) anyway. Coming at it from (3) is really only useful for fiddling with settings at the beginning of your project, i.e. before you actually have any real problems to solve.

Epilogue

Very long post I know, and I hope it doesn't sound like a rant! Very much appreciate you making this tool and sharing it with the world. I just wanted to explain why some of us find the tool difficult to use. I see there's been other issues in the past with similar requests, so hopefully this might help explain it further from the perspective of the users of the tool (who are specifically using this tool because we lack the knowledge to make it).

If this was a lot of work for you to do or had some downside, I'd understand the reluctance to bother with it. I can also understand giving the response: "it's open source, you can contribute and fix it yourself". But the work here isn't really any code/technical changes at all. The request here is for you to please put the knowledge you already have in your head down in writing with a few brief notes. Even just one sentence per option (noting the technical prioritisations made) would be incredibly helpful for us to differentiate them as users.

Given you built the tool, and needed to figure out (2) already, you're the only person who already has this knowledge. Even if somebody else attempted it, they're still going to just be writing the descriptions based on assumptions about what you had in mind as you've built the tool, so it's probably going to be wrong anyway.

I see people are asking you questions in the github issues here about the differences between the options, so maybe just publishing that info up front might even save you some time in answering these questions again and again?

If you were to type up some info, I'd suggest just putting it on the homepage under the text:

You need provide basic information about your hardware configuration, where is working PostgreSQL database. Results will be calculated after clicking "Generate" button

...that way it's already on screen exactly when the user needs to read it. And they're less likely to come and bug you with questions about them here. :)

Cheers & thanks for you consideration on this topic again!

[le0pard]

Hello. This types was taken from original cli pgtune. Here discussion about this - gregs1104/pgtune#2

I can create separate page with explanation, if this needed. Does this explanation in gregs1104/pgtune#2 (comment) will be enough for this DB types @hi2u ?

[hi2u]

Oh cool, that info looks very useful!

Yeah we could basically just paste that info into the homepage I think.

separate page

Personally I think it would be best to just stick it on the homepage in the empty space to the right of the form, e.g. quick mockup:

...that way it's right there for the user to see side-by-side on one screen. And currently it's just a big empty space anyway... so might as well make it useful rather than the user having to open multiple browser tabs, which are harder to view side-by-side.

And this extra visibility might also encourage people to update the text too, if they have some further info they might be able to add (based on their knowledge of the postgres settings affected).

And as a bonus, you'll get a few more keywords on the homepage for SEO.

I'm happy to make the change if you like, and submit a PR?

[le0pard]

@hi2u if you would like, you can make PR. If you will not have time - it is also ok, I will add this later. Thanks.

[le0pard]

@hi2u added by 069afd3 . You can check result

[hi2u]

Awesome, thanks so much for doing this!