Com o PostgreSQL 12 e o PostGIS 3, os planos de consultas paralelas ser\u00e3o gerados e executados com muito mais frequ\u00eancia, devido a altera\u00e7\u00f5es nos dois softwares:<\/p>\n
- \n
- O PostgreSQL 12 inclui uma nova API<\/a> que permite que extens\u00f5es modifiquem planos de consulta e adicionem cl\u00e1usulas de \u00edndice. Isso permitiu ao PostGIS remover um grande n\u00famero de fun\u00e7\u00f5es SQL embutidas que anteriormente estavam atuando como barreiras de otimiza\u00e7\u00e3o.<\/li>\n
- O PostGIS 3 aproveitou a remo\u00e7\u00e3o das linhas SQL para re-custear todas as fun\u00e7\u00f5es espaciais com custos muito mais altos. A combina\u00e7\u00e3o de fun\u00e7\u00e3o inlining e altos custos fazia com que o planner tomasse m\u00e1s decis\u00f5es, mas com as atualiza\u00e7\u00f5es no PostgreSQL isso agora pode ser evitado.<\/li>\n<\/ul>\n
Aumentar os custos das fun\u00e7\u00f5es do PostGIS nos permitiu incentivar o planner do PostgreSQL a ser mais agressivo na escolha de planos paralelos.<\/p>\n
As fun\u00e7\u00f5es espaciais do PostGIS s\u00e3o muito mais caras em termos computacionais do que a maioria das fun\u00e7\u00f5es do PostgreSQL. Um c\u00e1lculo de \u00e1rea envolve muita matem\u00e1tica envolvendo todos os pontos de um pol\u00edgono. Uma interse\u00e7\u00e3o, reproje\u00e7\u00e3o ou buffer pode envolver ainda mais. Por esse motivo, muitas consultas PostGIS est\u00e3o com gargalo na CPU, n\u00e3o em I\/O, e est\u00e3o em uma excelente posi\u00e7\u00e3o para aproveitar a execu\u00e7\u00e3o paralela.<\/p>\n
Uma das fun\u00e7\u00f5es que se beneficia do paralelismo \u00e9 a j\u00e1 conhecida ST_AsMVT()<\/a>. Quando houver linhas de entrada suficientes, a fun\u00e7\u00e3o ser\u00e1 expandida e paralelizada, o que \u00e9 \u00f3timo, pois as chamadas ST_AsMVT () geralmente encerram uma chamada para a dispendiosa fun\u00e7\u00e3o de processamento de geometria, ST_AsMVTGeom()<\/a> .<\/p>\n
\n![\"\"](\"http:\/\/www.fernandoquadro.com.br\/html\/wp-content\/uploads\/2020\/03\/tile100.png\")
\n<\/center><\/p>\nUsando a camada Admin 1 de estados e prov\u00edncias do Natural Earth como entrada, foi executado um pequeno teste de desempenho, construindo um Vector tile para o n\u00edvel de zoom um.<\/p>\n
\n![\"\"](\"http:\/\/www.fernandoquadro.com.br\/html\/wp-content\/uploads\/2020\/03\/graph.png\")
\n<\/center><\/p>\nO desempenho das consultas espaciais parece ter uma escala quase igual \u00e0 n\u00e3o espacial, \u00e0 medida que o n\u00famero de n\u00facleos aumenta<\/a>, levando 30 a 50% menos tempo com cada duplica\u00e7\u00e3o de processadores, portanto n\u00e3o linearmente.<\/p>\n
A jun\u00e7\u00e3o, as agrega\u00e7\u00f5es e as verifica\u00e7\u00f5es se beneficiam do planejamento paralelo, embora, como os ganhos sejam sublineares, haja um limite<\/a> para a quantidade de desempenho que voc\u00ea pode extrair de uma opera\u00e7\u00e3o adicionando mais processadores. Al\u00e9m disso, opera\u00e7\u00f5es que realizam uma grande quantidade de processamento computacional em uma \u00fanica chamada de fun\u00e7\u00e3o, como ST_ClusterKMeans<\/a>, n\u00e3o s\u00e3o paralelizadas automaticamente: o sistema s\u00f3 pode paralelizar a chamada de fun\u00e7\u00f5es v\u00e1rias vezes, n\u00e3o o funcionamento interno de fun\u00e7\u00f5es \u00fanicas.<\/p>\n
Fonte: Clever Elephant Blog<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
A consulta paralela faz parte do PostgreSQL desde 2016 com o lan\u00e7amento da vers\u00e3o 9.6 e, em teoria, o PostGIS deveria se beneficiar do paralelismo desde ent\u00e3o. Na pr\u00e1tica, a natureza complexa do PostGIS significou que pouqu\u00edssimas consultas poderiam ser… Continue Reading →<\/a><\/p>\n","protected":false},"author":275,"featured_media":8753,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[212],"class_list":["post-8740","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gis","tag-postgis"],"_links":{"self":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/8740","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/users\/275"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/comments?post=8740"}],"version-history":[{"count":5,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/8740\/revisions"}],"predecessor-version":[{"id":8754,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/8740\/revisions\/8754"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/media\/8753"}],"wp:attachment":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/media?parent=8740"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/categories?post=8740"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/tags?post=8740"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- O PostGIS 3 aproveitou a remo\u00e7\u00e3o das linhas SQL para re-custear todas as fun\u00e7\u00f5es espaciais com custos muito mais altos. A combina\u00e7\u00e3o de fun\u00e7\u00e3o inlining e altos custos fazia com que o planner tomasse m\u00e1s decis\u00f5es, mas com as atualiza\u00e7\u00f5es no PostgreSQL isso agora pode ser evitado.<\/li>\n<\/ul>\n