@bg1900 Is this on a self-hosted version of Retool or Retool cloud? If self-hosted, what version are you on?
The time taken to transfer the query and results between the Retool backend and frontend.
does this imply that the issue is at Retool's end internally
This does imply that the largest amount of time for this query is in the transfer of the data from the Retool backend to the frontend. Is this happening in all your postgres queries?
Can you share a sample of what one row of data might look like? ie: what data types columns are for this table etc.
Due to data privacy concerns I canno tshare the data. But I can tell you it is currently ~80 columns, all varchar type. Short amounts of information in each (ranging from blank/null to ~30 characters)
Please let me know if there is further information that you need
Since this is cloud hosted, if you share your subdomain or org name, I should be able to look up some logs. Feel free to DM that information if you prefer.
Is this happening in all your postgres queries? Do you also get a response size in the query processing time breakdown? And to confirm the 4.9s total time is for 1 row of data?
Hey @bg1900, still unable to repro and we don't see any general latency spikes with Postgres resources. Can you share a sanitized sample data (1 row is sufficient) so that we can get an idea of what is going on. Would also be helpful to have the name of the resource and the name of one of the queries that is taking an extended amount of time to return so that I can dig into the logs for your instance. Thanks.
Thank you for looking into it further.
Can we message off the forum board to look into this further. I will happily provide you all the information you need.
ah so interestingly, for those playing along at home, it seems that the issue is Retool trying to load 2 other small javascript queries at the same time.
I am not sure why Retool reports that as a delay in transfer data but the issue resolves if those other scripts are stopped.