so,
You do a query for
Test1,Test2,Test3 and Test4 at exactly 2014--08-05T18:45:11
then you do a second query for the same tags but for the different timestamp
Test1,Test2,Test3 and Test4 at exactly 2014-08-05T14:45:11
in the "General" tab, update the row-count to 2.
In the "DateRange" tab, update the
start timestamp to 2014-08-05T18.45:11
end timestamp to 2014-08-05T18:45:12
Duration should be set up to 1
Duration units, should be "seconds"
Interval count should be 1
In the "TagRetrieveQuery" tab, select Interpolate view so that you make sure the historian will return a value, even interpolated.
You'll have to do a second call for the second timestamp.
If you run the query above, what you'll get is a set of two values for each tag. One at the beginning of the 18:45:11 second and one at the beginning of the 18:45:12 second, that is, before and after the historian recorded the values during that second you're interested in. If no value is recorded by the historian, the two values obtained via PCo will be the same.
Now, the historians are not relational databases. You can't do "join" or "union" queries grouped together by various "where" parameters. Some of the historians in fact "are" based on the SQL server, but in order to be able to log 5000 point per second, they use a lot of curious configurations with data files one cannot access directly.
If you're worried about performance, you can't go over 2000 queries per second, provided that the infrastructure supports those query rates. The Osisoft-PI SDK limits you to about 100 queries per second workable rate. Wonderware and SimaticIT, as SQL based historians are way lower (about 20 / second) using 32Gb RAM and dual xeons & 10k drives for about 5000 tags dedicated SQL server environments.
I'd update the functional requirements so that you have to do less queries per second than your maximum is (as found during stress testing). You need to leave the historian to do what it's supposed to do (i.e. record the data), before you start reporting on it.