[SOLUCIONADO] Duda sobre rapidez en loops

[dehm]

Hola:

Esta es una duda muy general, y seguro que no esté diciendo nada importante, pero el caso es que tengo una función cuyo LOOP se basa en una cláusula WHILE

Código SQL:

WHILE x < (SELECT COUNT(*) FROM prueba4)
 

Forma parte de una función para añadir un caracter '0' a una tabla de códigos postales, en aquellos que tienen 4 caracteres.

Estamos hablando de 153.000 registros más o menos, y puede tardar bastantes minutos.

Y otra función hecha con FOR registro IN ..... va mucho más rápida, mas o menos 2-3 segundos.

Evidentemente no hacen lo mismo, pero me da la impresión de que la diferencia de rapidez está más en la forma de plantear el ciclo que en el contenido del mismo, ya que dicho contenido es muy básico en ambos casos.

¿Puede ser así?
Saludos y gracias.

[huesos52]

Hola dehm

Realmente la diferencia si está mas en el contenido de la misma que en el ciclo como tal.
Todo depende de la rapidez de la consulta con la que se ejecute el ciclo.

Saludos

[dehm]

Tienes toda la razón.
Cuando escribí este mensaje no me paré realmente a evaluar el contenido del ciclo.

Creo, y a lo mejor digo de nuevo una tontería, que la diferencia (en el caso concreto que motivó mi consulta) entre una u otra forma se debió a que en una forma planteé el contenido del bucle así:

Código SQL:

DECLARE
    x INTEGER;
    registro RECORD;
BEGIN
    x:=1;
    --WHILE x < (SELECT COUNT(*) FROM prueba4)
    FOR registro IN SELECT * FROM prueba4 ORDER BY id
    LOOP
        IF LENGTH(registro.cp)<5 THEN
        UPDATE prueba4 SET cp=(lpad (cp,5,'0'))WHERE prueba4.id=x;
        RAISE NOTICE'(%)',registro.cp;
        END IF;
        --RAISE NOTICE'(%)',x;
        x:=x+1;
    END LOOP;
END;
 

y en la otra así:

Código SQL:

DECLARE
    x INTEGER;
BEGIN
    x:=1;
    WHILE x < (SELECT COUNT(*) FROM prueba4)
    LOOP
        UPDATE prueba4 SET cp=(lpad (cp,5,'0'))WHERE prueba4.id=x AND LENGTH(cp)<5;
        --RAISE NOTICE'(%)',cp.cp;
        x:=x+1;
    END LOOP;
END;
 

Pienso que la doble condición del UPDATE unido a que no hay previamente una cláusula IF que elimine algunos registros fue el determinante de que una operación fuese casi instantánea y la otra se llevase su tiempo.

Yo soy novato en las BBDD así que si digo muchas tonterías me lo decís

Y digo yo, si esto es así....¿cuando alguien trabaja con BBDD "de verdad" con millones de registros, ha de plantearse y hacer pruebas de rapidez antes de lanzarse a hacer un UPDATE o cualquier otra operación, con vistas a ahorrar tiempo?

[huesos52]

Claro que si.

Para este tipo de operaciones a gran escala y de procesamiento de millones de registros, existen los planes de ejecución, donde postgresql o cualquier otro motor de bases de datos decente, basado en las estadísticas y el movimiento de registros, nos indica la ruta que tomaría las sentencias y el costo que esto implicaría antes de ejecutar la sentencia.

Previamente, el especialista en bases de datos analiza este plan de ejecución y decide si es viable o no su ejecución.

[gnzsoloyo]

Cuando se trabaja productivamente en bases de datos empresariales, cambios menores des escenario, obligan a cambiar completamente la estrategia de una consulta. Y a veces una consulta "perfecta" con dos millones de registros, deja de ser buena cuando llegas a tres millones.
Por eso el análisis de la optimización se debe hacer también periódicamente.

Tengo casos de consultas y procesos que anduvieron maravillosamente durante varios años, y un buen día empezaron a caer en error.
¿Por qué?
Porque por obligaciones legales se agregó un dato a una tabla, y se sumo ese dato como parámetro en las consultas, pero ese dato destruyó la performance de mas de una query...

Hubo que rehacer la lógica de más de una decena de SP.

[dehm]

Muchas gracias por las respuestas!