The DITA specification uses the OASIS CALS spec for tables (at least that is the only table type in DITA that supports widths in the markup). This table model is very different from HTML, which is what most people are familiar with (if they are familiar with any kind of table model).
Unlike HTML, you cannot directly specify an overall table size with CALS and have the columns expand to fill it. Or you can (using proportional sizes), but if you do then you have no control over the exact size of the table. If you want to control the exact size of the table then you need to use fixed width columns. You can then use the pgwide attribute on the table element itself if you want to change the behaviour of the overall table size:
In DITA tables, in place of the @expanse attribute used by other DITA elements, the @pgwide attribute is used in order to conform to the OASIS Exchange Table Model. The @pgwide attribute has a similar semantic (1=page width; 0=resize to galley or column).
If you want a table to be a specific size you set all columns using fixed width units (cm, in, etc) and not * (proportional). If you have one or more columns in a table set using proportional width then it will fill in any remaining space after any fixed width columns have been set.
Note that the deliverable "XMetaL Enhanced PDF via RenderX XEP" does not respect the pgwide attribute, so if you want PDF output with tables that are not full width you will either need to modify it or use another deliverable that outputs PDF.
Table widths or formatting of any kind in XML is tending away from the concept of separating content from style. For the two main table models in use with XML (HTML and CALS) their markup tends to "pollute" the rest of the content (my opinion). Producing different outputs from this kind of markup can be troublesome (or at least extra work) if the widths, or other table settings that are essentially style, are important to you. You may end up needing to produce a duplicate table with slightly different settings for different outputs for DITA, if you produce both PDF and HTML. Conditional text could be used to do that, or you might prefer to alter how the DITA Open Toolkit handles them.
An alternative is to set things up with another attribute (in DITA this might be @outputclass) that tells the DITA OT to lay out the entire table according to a standard set of stylist rules (which might be different for different outputs) but this would also require the DITA OT to be modified to recognize whatever values you choose for that and produce the desired table layout.