Hi, On Wed, 14 Jul 2021 07:58:14 +0200 "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> wrote: [...] > Could it be that a command saturated the network? > Jul 13 00:39:28 ltaoperdbs02 postgres[172262]: [20-1] 2021-07-13 00:39:28.936 > UTC [172262] LOG: duration: 660.329 ms execute <unnamed>: SELECT > xmf.file_id, f.size, fp.full_path FROM ism_x_medium_file xmf JOIN#011 > ism_files f ON f.id_file = xmf.file_id JOIN#011 ism_files_path fp ON > f.id_file = fp.file_id JOIN ism_online o ON o.file_id = xmf.file_id WHERE > xmf.medium_id = 363 AND xmf.x_media_file_status_id = 1 AND > o.online_status_id = 3 GROUP BY xmf.file_id, f.size, fp.full_path LIMIT > 7265 ;
I doubt such a query could saturate the network. The query time itself isn't proportional to the result set size. Moreover, there's only three fields per row and according to their name, I doubt the row size is really big. Plus, imagine the result set is that big, chances are that the frontend will not be able to cope with it as fast as the network, unless the frontend is doing nothing really fancy with the dataset. So the frontend itself might saturate before the network, giving some break to the later. However, if this query time is unusual, that might illustrate some pressure on the server by some other mean (CPU ? MEM ? IO ?). Detailed metrics would help. Regards, _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/