How to make sure a pg_dump data file was properly restored?

Question

I am a novice when it comes to postgres, so please if anything below reads confusing feel free to assume error on my part.

I "inherited" an academic project that used postgres to build a data viz and demonstration dashboard.

The project was dormant for a while and had a rather old version of postgres running and what I actually got from my predecessor is "pg_dump.sql" files.

I was able to follow setup helps given on the fedora help page.

Then use sudo -u postgres -i

Then createdb <database_name>

Then psql -U <username> -d <data_base_name>

Then I used psql -U username -d dbname < filename.sql to restore one pg_dump file. (I have used the role/user that the pg_dump.sql had)

When I do \dt, I get the following output:

       List of relations
 Schema | Name | Type  | Owner
--------+------+-------+-------
 public | test | table | piims
(1 row)

but when I do SELECT * FROM test LIMIT 500; I get the following message:

 id
----
(0 rows)

The pg_dump.sql file is huge with north of 3.8 million lines of text. At about line 2700 the pg_dump.sql file has a line with this syntax Data for Name: atgcat; Type: TABLE DATA; Schema: ionuser; Owner: piims and right below that syntax it has bioinformatics tabular data that looks familiar to my eye. Data that is missing from the "restored" database.

I tried the following syntax

SELECT 
    schemaname AS schema_name,
    relname AS table_name,
    n_live_tup AS row_count
FROM 
    pg_stat_user_tables
ORDER BY 
    n_live_tup DESC;

which then produced the following output:

schema_name |  table_name   | row_count
-------------+---------------+-----------
 ionuser     | obselem       |    532192
 ionuser     | normal        |    434981
 ionuser     | zscore        |    434981
 ionuser     | lineatg       |    395648
 ionuser     | pdiff         |    365206
 ionuser     | linecat       |    355161
 ionuser     | ppn           |    355158
 ionuser     | linecat_temp  |    353843
 ionuser     | parent        |    103452
 ionuser     | bgstat        |     77850
 ionuser     | pdstat        |     77850
 ionuser     | tube_elemnts  |     74454
 ionuser     | zstat         |     65601
 ionuser     | nstat         |     65601
 ionuser     | pot_elemnts   |     41688
 ionuser     | potbgexclude  |     39924
 ionuser     | atgcat        |     30676
 ionuser     | tube          |     29129
 ionuser     | potinfo       |     12294
 ionuser     | tubedets      |      7771
 ionuser     | compweight    |      5102
 ionuser     | traydets      |      4749
 ionuser     | potbg         |      2709
 ionuser     | orders        |       819
 ionuser     | ecotype       |       796
 ionuser     | trayinfo      |       309
 ionuser     | images        |       295
 ionuser     | wnanalysis    |       229
 ionuser     | typedets      |       201
 ionuser     | people        |       126
 ionuser     | ostat         |       110
 ionuser     | tubedef       |       108
 ionuser     | traydef       |        98
 ionuser     | atomic        |        30
 ionuser     | stdmtrl       |        13
 ionuser     | type          |        12
 ionuser     | status        |        10
 ionuser     | tlist         |         9
 ionuser     | icpmseq       |         5
 ionuser     | ppltype       |         5
 ionuser     | flag          |         3
 ionuser     | trayset       |         2
 ionuser     | calibmet      |         2
 ionuser     | elemlist      |         1
 ionuser     | rack          |         1
 ionuser     | rackshelf     |         0
 ionuser     | shelfposition |         0
 ionuser     | percentdiff   |         0
 public      | test          |         0
 ionuser     | shelf         |         0
(50 rows)

I the counts in the row_counts columns adds up to 3869204 which is quite close to the wc -l of the pg_dump.sql file (the file has 5,204 more lines). So, it looks like the tabular data from the file is in the database but not accessible or should not be accessible?

I am not sure what schema means in this context. Are the tables shown in the last table not meant to be accessible to me as a user? If no, could you point me in the right direction to understand the jargon at hand. If the data should be accessible, what should I do to make it so?

The data at hand is a product of few years worth of academic research and I want to recover it if possible.