That must be QUITE a table you are working with. There is currently a maximum number of 127 sets of prefixed fields and derived fields in a table. In theory, that number should accommodate most modeling requirements. What are you seeking to accomplish? It may be that I can propose a simpler way to execute the analysis you are attempting.
A couple of best practices that you may not have considered:
Start with no columns/fields of data: I had a tendency to start modeling from a table which already contained all of the columns of data from my dataset. By starting with no columns of data, I found I can use the DATA column to pull data fields into your table as you need them for your analysis work. You still retain access to all of the data source's fields, even though they aren't displayed in the table.
Fork your analysis: It is common to perform many different types of analysis on the same dataset. Analysis on different fields which aren't related can be done in a different workbook, or in a separate dataflow. By adding a temporary table back to your workbook, you can move in a different direction from the first time you worked with that table.
Slim down your table: To create a slimmer table, use the project operation to create a new table containing a subset of the current table's data.
With more information about what you are seeking to accomplish, I'm sure we can figure out how to get you there. How many columns were in your table? (How many sets of prefixed data columns and derived fields) and what was the operation you were attempting to perform?