UPDATE MyTable SET Statistic = GetStatistic(ID);
在select查询中,我使用列Statistic而不调用GetStatistic函数.
问题是,我的生产服务器有64个cpu和大量内存,因此几乎所有数据库都可以缓存到RAM,但是这个查询只使用一个cpu,需要2或3个小时才能执行.
GetStatistic函数使用表,在所有UPDATE查询执行期间都是常量.我可以修改查询以获得postgre,使用所有可用的cpu同时计算不同行的并行中的GetStatistic吗？
Pg擅长于许多较小查询的并发加载,并且很容易以这种方式使系统饱和,它只是在为一两个非常大的查询充分利用系统资源.
你能做的就是将工作分成几块,然后交给工人.你曾经提到过：
Can i modify query to get postgre to calculate GetStatistic in paralel
for different rows simultaneously,using all avaliable cpus?
有许多工具,如DBlink,PL/Proxy,pgbouncer和PgPool-II,旨在帮助完成这类工作.或者,您可以自己动手,开始(比方说)8个工作人员,每个人都连接到数据库并执行UPDATE … WHERE id BETWEEN？和？具有不重叠ID范围的语句.更复杂的选择是让队列控制器向工作人员分发大约1000个ID的范围,然后更新该范围然后请求新的.
请注意,64个cpu并不意味着64个并发工作者是理想的.在写入时,您的磁盘I / O也是一个因素.如果将UPDATE事务设置为使用commit_delay并且(如果对此数据的业务要求是安全的)则可以帮助您稍微降低I / O成本,则synchronous_commit =’off’则应显着降低同步负载.尽管如此,最好的吞吐量可能会远低于64名并发工人.
通过将GetStatistic函数转换为可内联的sql函数或视图,而不是大概是一个循环繁重的程序PL / pgsql函数,它很可能会快得多.如果您显示此功能可能会有所帮助.
