Alvaro, usando tu idea de actualizar registros que esten en diferentes
paginas o al menos que no todos esten en la misma, cree esta funcion,
empeze por el numero primero 37, pero vi que terminaba muy rapido y que
tenia periodos de bloqueos por encima de un minuto, no recuerdo si comente
que esta tabla tiene 2.3 millones de registos y el id es uuna sequencia
numerica, por tanto el max id tamnbien es 2.3 millones,
decidi utilizar esta query para analizar la cantidad de columnas que
serian afectadas de una vez, pues entre menor sea el numero menos
posibilidades de bloqueo cierto?
select id%10007 as divid, count(*)
from mobileusers
group by id%10007
order by divid asc
Con ese numero primo me da un promedio de 230 registros a la vez y
realizara solo 10 mil iteraciones, pero me preocupa esta tabla porque tiene
un alto volumen de escritura.
las tres columnas que voy agregar son de tipo boolean.
Esta es la funcion:
CREATE OR REPLACE FUNCTION addingcolumns7() RETURNS integer AS $$
DECLARE
i INTEGER := 0;
flag boolean := true;
BEGIN
while flag LOOP
UPDATE customers
set colum_1 = false,
colum_1 = false,
colum_1 = false
WHERE id%10007 = i ;
i:=i+1;
if i = 10007 then
flag := false;
end if;
END LOOP;
RETURN i;
END;
$$ LANGUAGE plpgsql
Lo otro que estoy pensando es utilizar los indices de la tabla, es decir la
tabla customer tiene una llave foranea de entidades a las que pertenece,
estoy pensando en seguir dividiendo por entidades, es decir solo afectar
una entidad a la vez pero nunca actualizando mas de 200 registros a la vez.
On Fri, Apr 5, 2019 at 9:53 AM Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Carlos T. Groero Carmona escribió:
> > Alvaro hice la function a partir de la idea que me distes, quizas no lo
> > entendi bien, solo que use 50 en lugar de 37.
> > esto es lo que me estas proponiendo?
> >
> > UPDATE table_1
> > set colum_1 = false,
> > colum_2 = false,
> > colum_3 = false
> > WHERE (id % 37) > 0 and (id % 37)<=36
>
> No. Quizás fui demasiado escueto.
>
> Lo que estaba proponiendo era un update con id % 37 = 0, luego otro (en
> otra transacción) con id % 37 = 1, luego id % 37 = 2, etc. Lo hice así
> con la esperanza de que las filas a actualizar se distribuyan
> uniformemente en la tabla, de manera que no todos los registros
> actualizados sean en las mismas páginas; así el siguiente update tiene
> más chances de hacer "hot update" para otros registros en las mismas
> páginas, reduciendo el trabajo que tendrá que hacer vacuum al final. Si
> haces "where id > foo and id < bar" entonces es muy probable que los
> registros actualizados estén todos juntos. Por eso el tiempo de espera
> entre un update y el siguiente también es importante; si el segundo
> update empieza inmediatamente después, es posible que no alcance a ser
> HOT debido a las transacciones concurrentes.
>
> No dijiste, creo, de qué tamaño era la tabla, ni los índices que tenía.
>
> > No he creado indices en esas columnas
>
> OK, eso permite que los update sean HOT.
>
> > tampoco seran llaves foraneas.
>
> Ya, pero acá la pregunta iba porque el UPDATE podría necesitar revisar
> las filas que referencian a las que sufren el update. Pero pensándolo
> bien, como las llaves UNIQUE/PK de tu tabla no cambian, esto no debería
> afectar.
>
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
