From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Jaime Casanova <systemguards(at)gmail(dot)com> |
Cc: | rug_vzla(at)hotmail(dot)com, Postgre SQL <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Rv: Tiempo de Consultas |
Date: | 2006-11-22 12:48:28 |
Message-ID: | 20061122124828.GA4076@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Jaime Casanova escribió:
> En EXPLAIN ANALYZE mira el "total runtime" la razon por la que \timing
> reporta un tiempo menor es porque acabas de ejecutar ese query y ya
> los datos estan en memoria...
Otra cosa que es importante saber, es que EXPLAIN ANALYZE hace muchas
llamadas a gettimeofday(). Esto es bueno, porque esa llamada es la que
le permite contar el tiempo. Pero en algunas maquinas (como en mi
maquina vieja Celeron) esa llamada se tarda bastante, por lo que un
EXPLAIN ANALYZE termina demorando mucho mas que la ejecucion de la
consulta sin EXPLAIN ANALYZE.
Por lo tanto lo que hay que hacer es determinar si gettimeofday() es
rapido o no en tu maquina; y si es lento, entonces hay que tomarse los
resultados de tiempo de EXPLAIN ANALYZE con escepticismo; pero no
descartarlos totalmente.
Hubo discusiones en pgsql-hackers al respecto hace no mucho tiempo. Se
estuvo experimentando con algoritmos para tomar solo un muestreo, o bien
descontar el sobrecosto de la llamada gettimeofday(), pero hay varios
problemas que lo hacen imposible (o por lo menos, no se ha encontrado
una solucion satisfactoria). La modificacion estuvo en la rama de
desarrollo de 8.2 durante un par de meses pero finalmente tuvo que ser
revertida.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Raul Andres Duque | 2006-11-22 13:29:06 | Re: Rv: Tiempo de Consultas |
Previous Message | Javier Estévez CIFA Córdoba | 2006-11-22 11:30:14 | Estadística con PosgreSQL y PHP |