Postgresql que se muere

[Marcos Ramirez]

On Thu, 2010-07-15 at 10:03 -0400, Franco Catrin L. wrote:
> El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió:
> > On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
> > > Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que
> > > ocupe cero bytes está lejos aún.
> > > Lectura recomendada:
> > > http://www.joelonsoftware.com/articles/LeakyAbstractions.html

> > Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) 
> > debe ser lo suficientemente robusta para no gotear errores inesperados,
> > pues es quien tiene toda la información de saber qué paso realmente.
> 
> Mi mirada al documento es respecto a cómo las abstracciones pueden jugar
> en contra cuando no sabes qué está pasando realmente por debajo, algo
> que queda claro al leer los comentarios en este thread.

> Un buen ejemplo que da el autor es cuando recorres una estructura de
> datos y perfectamente el programador puede recorrerla de una forma que
> el rendimiento se degrade.

Si quieres ver el otro lado de la moneda, siempre estaran los
programadores que piensan que la BD es "magica" y que sin importar las
sentencias SQL que usen, el rendimiento debe ser maximo o superior.

> Las "abstracciones que gotean" no son un error, son un hecho.  

Asi es. El punto es "cuanto goteo es razonable o aceptable". Hay cosas
que nigun motor puede hacer, como conseguir memoria donde no la hay,
pero si puede administrar bien la que tenga. 

Por citar el mismo ejemplo de Oracle que tu mencionaste antes, hay casos
en que una consulta puede ser extremadamente lenta, pero no entrega un
error de falta de memoria.

Saludos