Re: certificacion
Saludos! 2010/7/21 Daemon > Como dijo Blake Ross, "lo que importa es el conocimiento, como lo > adquiriste termina siendo irrelevante".. > Nadie discute que uno pueda saber. La diferencia esta en un pedacito de papel que lo dice. ;-) Saludos! -- Juan C. Inostroza
Re: Postgresql que se muere
Hola! 2010/7/14 Gonzalo Diaz > Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos > habrán inventado el sistema de excepciones en postgresql? > Las excepciones van dentro del codigo de PL/SQL. En este caso especifico, el motor de DB es el que esta teniendo el problema. Recomendado? Leer un buen libro de PL/SQL de pasadita para entender las excepciones ;-) > Cabe recordar que un SP se puede programar varios lenguajes ajenos. > > Tecnicamente, si. Aqui no estamos hablando de procedimientos almacenados, sino un problema dado en una consulta que se ve "inocente". Puede ser incluso que el dise~o de la tabla este medio malena. Pero bueh, eso ya queda para el que quiera dentrar a cepillar. Saludos! -- Juan C. Inostroza
Re: Postgresql que se muere
Hola! 2010/7/13 Ricardo Munoz > eso quiere decir que tendrias que poner mas memoria a tu servidor por cada > n-cantidad de nuevos registros que le agregas a la base de datos? eso no > tiene sentido... y fijate que el error se produjo con un simple SELECT > COUNT()... > > Como dije, puede sonar muy inocente la query. Pero no siempre puede ser problema de memoria. 1.- Concuerdo contigo que puede ser un bug de la aplicacion. Pero... 2.- Hay parametros para ajustar los valores de trabajo cuando se ejecuta un query. Tambien... 3.- El mismo kernel instruyendo al proceso que "deje de comer cpu/memoria/wharenes". Tambien se le puede echar la culpa al host :-) Tengo por ahi una query hecha sobre 4000*230 registros en MySQL que la deja pensando por un buen rato y en algunas maquinas es capaz de irse de ozzy. Curiosamente, la misma query en una version anterior, anda como avion... Saludos! -- Juan C. Inostroza
Re: Postgresql que se muere
Hola! 2010/7/13 Ricardo Munoz > da para pensar como tanta gente hizo la pega (buscar en Google) del autor > del primer mail y/o respondieron a la rapida y mal. cualquier usuario de un > motor de base de datos debe saber que > ... > - el resultado de un SELECT nunca puede ser un mensaje de error de memoria > > - el resultado de un servicio mal optimizado nunca puede ser un mensaje de > error de memoria durante su operacion (instruccion SELECT), sino solo al > momento de subir el servicio > > por lo tanto, la unica explicacion logica al problema es que > > - se trata de un bug de Postgres, donde la solucion es actualizar ojala > usando el metodo ofrecido por la distro de Linux > No necesariamente. Hay algunos "problemillas" que he pillado ultimamente en MySQL que a veces tiran a hacer consumo excesivo de memoria (como algunos subselects). Y tecnicamente, se arreglan haciendo algunos ajustes al mismo query. > - se trata de un error de hardware (memoria o disco), donde la solucion es > reemplazar el hardware malo o cambiar el servicio a otra maquina > Me gustaria ver los valores de los parametros que mande antes. Quizas podrian decir, o bien que es el mismo bug (un rapido googleo) o bien que la tabla ni siquiera esta optimizada. Saludos! -- Juan C. Inostroza
Re: Postgresql que se muere
2010/7/13 Marcelo Espinosa Alliende > El Tue, 13-07-2010 a las 14:27 -0400, Andres Junge escribió: > > Hola > > Gracias por contestar. Que cosas podria "tunear" por ejemplo? > > Parte testeando la memoria de la maquina :) > > Habia un truquito usando el valor de maintenance_work_mem y work_mem. Prueba moviendo esos valores. Saludos! (nota : mi cuenta de correo is alive :D ) -- Juan C. Inostroza
