Tablas Grandes : 2 Consultas

[seyko]

Buenas

Agradezco inmensamente sus valiosas recomendaciones, por lo cual ya estoy tratando de implementar sus aportes en relación al problema. Aunque ahora tengo mayor claridad, en la necesidad de encontrar nuevas formas de unir el resultado de las funciones sql que permiten visualizar los datos de las tablas, continuo con una duda, en relación, no ya con el tamaño de las tablas, sino con la estructura o tipo de dato con que se visualiza la salida Vs el rendimiento o velocidad con que se forman tales tipos. Para ello, he realizado unas pruebas a partir de 101.570 registros, bien lejos de lo inicialmente planteado que eran 1.5 millones de registros, obteniendose lo siguiente :
a. Se dispone de una función SQL, cuyo tipo de dato de salida es un SETOF, que devuelve 12 Columnas, la cual a su vez llama a dos funciones que crean vistas :
a.1. La función que crea la Vista1, con 12 columnas, requiere de 48.38 sec, para formar la vista que contiene 10.157 Registros y devuelve ademas un Integer que indica el total de registros. ¿ Está este tiempo de respuesta, dentro de lo que puede aceptarse como normal?
a.2. La funcion que crea la Vista2, con 6 columnas, que recibe como parametro de entrada un Id, producido por cada registro de la Vista1 y para cada Id, devuelve una vista de 10 registros ( de allí la cantidad total de Registros del Setof : 10x10.157=101.570 registros). Esta vista se genera en muy pocos ms.
El tiempo total para generar el setof es de 10.121 sec, es decir, el setof se forma a una velocidad aproximada de 600 Reg/min, rendimiento este que me parece muy pobre, por lo que agradezco me idiques tu opinión al respecto. Ahora bien, dado que ese SETOF debe ser convertido en un Refcursor , a ser abierto directamente desde el PgAdmin o desde el Web, se requerirá entonces un minuto adicional, es decir, que solo podría visualizarse 600 Reg/2 min o 300 Reg/min.
El procedimiento que he seguido, como se indica, utiliza vistas, y tu propuesta utiliza una tabla temporal, pero en conclusión, considero que producen los mismos resultados.

El rendimiento no se mide en tiempo, porque influyen muchos factores.
VACUUM y EXPLAIN ANALYZE te pueden ayudar a ver donde está el "problema".

Si en tu opinión, los rendimientos indicados, estan dentro de los valores normales (pues ya no me quedan muchas opciones para optimizar el codigo), entonces definitivamente, la cantidad de registros que se encapsulan en el refcursor no debería exceder de 300, si se desea que el tiempo maximo de respuesta sea de un min.

Hombre, esto es muy muy relativo. Siempre se puede hacer algo más.
postgresql.conf es el archivo de configuración, donde tienes muchos parametros que puedes modificar para mejorar el rendimiento.

Debo admitir que tienes toda la razón en cuanto a mi confusión con los indices, sin embargo, el problema subsiste aún en tablas en las que no se ha realizado ningun DELETE.

Te lo cuento con un ejemplo.

Código:

aemprende=# create table aaa (id serial primary key, nombre varchar not null);
NOTICE:  CREATE TABLE creará una secuencia implícita «aaa_id_seq» para la columna serial «aaa.id»
NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «aaa_pkey» para la tabla «aaa»
CREATE TABLE
aemprende=# insert into aaa values (default, 'jose');
INSERT 0 1
aemprende=# insert into aaa values (default, null);
ERROR:  el valor null para la columna «nombre» viola la restricción not null
aemprende=# insert into aaa values (default, 'pepe');
INSERT 0 1
aemprende=# select * from aaa;
 id | nombre
----+--------
  1 | jose
  3 | pepe
(2 filas)

al fallar el insert, el valor de la secuencia ya se ha capturado, por ello queda el hueco, no es necesariamente por un delete.

Si ves que la cosa sigue mal y es critico lo podemos mirar con más calma por privado.

Un saludo