The whole point of a WMS service (or really, any service) is to hide specifics of the underlying database to users, so you only have to deal with a generic WMS interface rather than something database specific. So, no, there is no way, other than asking the owner, to get more information.
As for getting the data into an attribute table, your best bet would ...
The IN operator allows you to specify multiple values in a WHERE clause.
The IN operator is a shorthand for multiple OR conditions.
when "field1" IN('5','6') then 'pro' --IN(5, 6) if field1 is numeric
--more when condition goes here
You're doing a full table scan query on features with tens of millions of vertices. Yeah, that will take a while. Adding additional geometries to the table likely made it worse (more pages in the table).
The key to good draw performance with massive polygons is to not draw them.
Instead you can convert the boundaries to lines, intersect the lines with a 9x9, ...
An alternation using processing tools and expressions (I know it's OT, but it might be useful)
Aggregate algorithm, set as below:
field to group
expression to use
You'd want to run:
SELECT JSONB_BUILD_OBJECT( --aggregate features into FeatureCollection
) AS featurecollection
--subquery to generate GeoJSON Features from "table_rows", aliased "AS features"
SELECT JSONB_BUILD_OBJECT( --...
Depending on your use case it might be worth trying to subdivide the geometries. Paul Ramsey has a nice article on that.
Subdividing will multiply your feature count and lead to many "duplicates" regarding their attribute values but each of the new features will have its geometry only cover a smaller region. Even when using the whole table anyways, ...
The problem is that if a point is within polygon A, it is also outside of polygon B. To overcome this, you can use a where exists clause to ignore points that are within any polygon.
Note that we don't need to compute the intersection (st_intersection) itself, we just need to know if they intersect or not (st_intersects)