Em 5 de abril de 2011 19:55, Flavio Henrique Araque Gurgel <fha...@gmail.com> escreveu: >> Apenas para ratificar então, o work_mem é por conexão, mas é um >> limitador apenas, não uma memória préalocada, ok? > > O work_mem não é por conexão.
Não é esta a minha interpretação e a minha experiência. > Do manual: > "Note that for a complex query, several sort or hash operations might > be running in parallel; each operation will be allowed to use as much > memory as this value specifies before it starts to write data into > temporary files." Tradução livre: "Note que para uma consulta complexa, algumas operações de hash ou ordenação poderão estar rodando em paralelo; cada operação poderá usar tanta memória quanto o especificado por este valor, antes de iniciar a escrita nos arquivos temporários." > Explica que o work_mem pode ser alocado diversas vezes numa consulta complexa. > Sim, o work_mem é um limite, não é uma alocação imediata. Ok, mas é um limite POR sessão e não para todo o cluster, como é o SHARED_BUFFERS. Confere? Apenas reforçando, logo em seguida, na mesma documentação temos: "Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value." Tradução livre: "Além disso, várias sessões podem estar rodando estas operações concorrentemente. Então o total de memória utilizada pode ser várias vezes o valor de WORK_MEM; é necessário ter este fato em mente quando for escolher este valor. Desta forma, o cálculo do WORK_MEM deve sim levar em conta o número máximo de conexões. Veja a recomendação do Gregory Smith em "PostgreSQL 9.0 Hight Performance": "In practice, there aren't that many sorts going on in a typical query, usually only one or two. And not every client that's active will be sorting at the same time. The normal guidance for work_mem is to consider how much free RAM is around after shared_buffers is allocated (the same OS caching size figure needed to compute effective_cache_size), divide by max_connections, and then take a fraction of that figure; a half of that would be an aggressive work_mem value. In that case, only if every client had two sorts active all at the same time would the server be likely to run out of memory, which is an unlikely scenario." Espero com isso ter clareado o assunto. -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
