Gunnar Wolf escribió:
> OK, interesante consejo, y tiene algo de sentido. Sin embargo... Se ve
> que tengo que hacer algo de trabajo antes de implementarlo, porque,
> con 8.5GB libres (y una BD que ocupa 6.6G),
Hmm, 6.6 GB para unos cuantos keyring? Suena excesivo ...
Noté recién que tienes ORDER BY en las definiciones de algunas vistas, los
cuales yo también quitaría, a menos que el orden tenga importancia (que
no me lo parece).
Creo que gran parte del problema son está en esta vista y
people_metadata:
CREATE OR REPLACE VIEW pubkey_metadata_equivalence AS
SELECT DISTINCT pkm1.keyid AS original_keyid,
pkm2.keyid,
pkm2.name,
pkm2.email,
pkm2.algorithm,
pkm2.created_at,
pkm2.expires,
pkm2.comment
FROM pubkey_metadata pkm1
JOIN pubkey_metadata pkm2 ON pkm1.email = pkm2.email
ORDER BY pkm1.keyid;
Acá te recomendaría quitar el ORDER BY, que no te está haciendo ningún
favor. Es mejor aplicar ORDER BY al resultado final, al consultar la
vista. De todas formas, estás ignorando name, algorithm, created_at,
expires, comment de la original_keyid, ¿no? Me parece que esta vista
está "perdiendo datos", y más bien lo que quisieras es el conjunto de
todos los keyid de un mismo email:
SELECT array_agg(keyid) FROM pubkey_metadata GROUP BY email;
Y a continuación puedes extraer toda la info de cada llave en cada uno
de esos arrays; (te construiría un ejemplo pero seguro que me equivoco,
sin tener datos de prueba a mano).
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
