As I am sure you have deduced, there isn't really a "general" answer. It is dependent on many things.
How fast is your query.
How good is your connection between the client and the gateway.
How good is your connection between the gateway and the DB.
What kind of load is the DB under?
What kind of load is the Gateway under?
How many indexes are in the table you are querrying?
Are you performing joins in the query?
Are you performing unions?
Is the data running through any kind of transform?
What is that transform doing?
etc....
No, because in my opinion, displaying 1000 rows of data to a user is useless. Instead, I do things like when a user clicks on a data point, present that row and only that row. ( I haven't done this in perspective just yet, but I will) Or I will have filters which will allow the user to pull the data that they are interested in. I very rarely find my self presenting huge blocks of data to a user, and when I do I take a step back and consider if there is a more user friendly and visual way to communicate what I'm trying to communicate.
I have loaded a 1000 rows in Perspective quickly, it seemed instant, Iām guessing under a second (I didnāt time it). But, to @lrose point, it isnāt wise. I did it to test. An operator being presented with that much data canāt be good.
It is not an option to not do for me. It is the requirement of the page to display the last several days of OEE data for several machines. So I need a way to do it efficiently.
As just that one page, one page, one configuration, I got the query down to less than half a second.
Another page, another way, I pull the data from a dataset tag.
Both have 7 seconds delay.
If someone has setup 1000 rows to show up faster than a second in perspective, I want to copy that technique.
I want to find out which of the things LRose mentioned are the cause of the delay.
I think maybe I need to make an XY container and just a 1000 row table from a tag to test.
I donāt think it is the database connection, because even from the tag, I get the delay.
Just to clarify, I was only showing a myriad of reasons that your performance could be slower than expected, I didn't even come close to listing them all.
That is the point we've been trying to make. Performance is specific to your task on your system. Sure, we might be able to point you in the direction of best practices or what not, but at the end of the day it will be dependent on your system.
As a point of reference, I can query 20K+ rows in less than 0.5 secs on my system, with 12 columns of data and a single index.
If it is important that you make this performant, then as suggested, contact support. We can't optimize what you're trying to optimize without seeing it.
Hopefully, not for an operator. I can see the downtime reports here, "Down for 5 mins searching for data in table"
Sometimes people really don't know what they're asking for.
Well, that might be a bit more to ask of support than support is really for. See the support policy. This is the kind of thing customers are expected to pay IA sales engineering for. Or pay another integrator.