if you look at the help tab on the processing window, you should (hopefully) see a small web page with help for the algorithm (it'll just take you to the page you linked to in your question, but can save you a trip over to a browser window)
I seem to have a slightly different layout to you, you may have a slightly different version of QGIS and/or Grass to me.
I see the following summary:-
v.net.distance [-gl] input=name output=name [arc_layer=string] [arc_type=string[,string,...]] [node_layer=string] [from_layer=string] [from_cats=range] [from_where=sql_query] [to_layer=string] [to_type=string[,string,...]] [to_cats=range] [to_where=sql_query] [arc_column=name] [arc_backward_column=name] [node_column=name] [--overwrite] [--help] [--verbose] [--quiet] [--ui]
things in square brackets are optional. Ellipsis (...) means things can be repeated
Description files
Somewhere on your system there is a text file which QGIS uses to set up the processing dialog. It'll be called v.net.distance.txt.
If you can't find it in your file system, the Grass 7 description files are here on Github. But those may be more up-to-date than what you have installed.
I don't recommend editing this, but it shows the types, defaults and options for each parameter. (For me, on ubuntu, I'd need to be administrator to edit the file, but not to read it).
In my system this looks like this:-
v.net.distance
Computes shortest distance via the network between the given sets of features.
Vector (v.*)
ParameterVector|input|Input vector line layer (network)|1|False
ParameterVector|from_points|Input vector point layer (from)|0|False
ParameterVector|to_points|Input vector point layer (to)|0|False
ParameterNumber|threshold|Threshold for connecting centers to the network (in map unit)|0.0|None|50.0|False
*ParameterSelection|arc_type|Arc type|line;boundary;line,boundary|2
*ParameterString|from_cats|From Category values||False|True
*ParameterString|from_where|From WHERE conditions of SQL statement without 'where' keyword||True|True
*ParameterSelection|to_type|To feature type|point;line;boundary|0
*ParameterString|to_cats|To Category values||False|True
*ParameterString|to_where|To WHERE conditions of SQL statement without 'where' keyword||True|True
*ParameterTableField|arc_column|Arc forward/both direction(s) cost column (number)|input|0|True
*ParameterTableField|arc_backward_column|Arc backward direction cost column (number)|input|0|True
*ParameterTableField|node_column|Node cost column (number)|from_points|0|True
*ParameterBoolean|-g|Use geodesic calculation for longitude-latitude locations|False|True
OutputVector|output|Network_Distance
The ones starting with "*" go into the advanced section, as far as I can see. The bit between the first and second pipe characters is the name of the GRASS parameter, which you can look up in the help. The bit in the next field is the label which appears in the dialog.
This trick can be useful if you find the label ambiguous or unclear.
As Joseph says, some of these are actually routed to v.in.ogr (or v.out.ogr) instead, but these are clearly labelled.
As mentioned by malcolm
I did a little research on GitHub (I should have started here, but I did not think it was a bug) https://github.com/qgis/QGIS/pull/9203
The behavior of QGIS 3.4.5 being slow at opening an attribute table in a PostGIS in the cloud of Azure being very slow (36 seconds)
It is a situation in which the developers are working on, it has already been fixed in QGIS 3.6 however, the backport to QGIS 3.4 (LTR) is still needs more tests.
To recapitulate everything discussed in this question:
Working with QGIS and a remote PostGIS in a cloud like Azure at a considerable distance (100ms ping to servers) Here are some considerations:
you want your client as close to the database as possible, client and host being close to eachother eliminates a lot of bottlenecks when working in a network
For high production environments maybe you want to consider a high connection +100 Mbits or 4000 IOPs between the client and the server where the PostGIS is located
About the specific case: QGIS 3.4.5 presents a problem when opening the attribute tables in a PostGIS in the cloud. the fix is expected to come out in the next point release (QGIS 3.6 does not present the problem)
This means that QGIS can be used perfectly with PostGIS in the cloud without the need for a "super" network or "super" server (+ 100Mbits or 4000IOPs), as long as production needs are low. This option of having a PostGIS in the cloud is a viable for small projects.
Best Answer
Have you thought about using an IaaS such as Amazon Web Services to host your GIS stack? There are a bunch of Amazon Machine Images (AMI) that already fulfill your requirements. You could spin up an Amazon EC2 instance to run your GIS jobs and manage it remotely from your laptop.
Here is a course that could get you spun up fairly quick (look at lessons 1-3):
https://www.e-education.psu.edu/cloudGIS/
Here is a nice VM bundle that you could deploy on an IaaS that has most of your dependencies:
https://github.com/zhm/geobox