2012-04-04 6 views
5

La siguiente consulta SQL de Postgres mostrará una lista de todas las tablas de todos los esquemas y sus tamaños y tamaños de índice. Si una tabla es solo una tabla de índice, aparecerá como índice 100%.¿Simplifica una consulta SQL de Postgres para listar tabla y tamaños de índice?

SELECT schema, 
     name, 
     pg_size_pretty(CASE WHEN is_index THEN 0 ELSE s  END) AS size, 
     pg_size_pretty(CASE WHEN is_index THEN s ELSE st - s END) AS index, 
     CASE WHEN st = 0 THEN 0 
      WHEN is_index THEN 100 
          ELSE 100 - ((s*100)/st) END || '%' as ratio, 
     pg_size_pretty(st) as total 
    FROM (SELECT *, 
       st = s AS is_index 
      FROM (SELECT nspname as schema, 
         relname as name, 
         pg_relation_size(nspname || '.' || relname) as s, 
         pg_total_relation_size(nspname || '.' || relname) as st 
        FROM pg_class 
      JOIN pg_namespace ON (relnamespace = pg_namespace.oid)) AS p)               
    AS pp                 
ORDER BY st DESC LIMIT 30; 

que dará a los siguientes resultados:

schema   |   name   | size | index | ratio | total 
----------------+------------------------+---------+---------+-------+--------- 
public   | conf     | 4072 kB | 4360 kB | 52% | 8432 kB 
archive  | product_param   | 4048 kB | 3968 kB | 50% | 8016 kB             
public   | conf_pkey    | 0 bytes | 4320 kB | 100% | 4320 kB 
archive  | product_value   | 1568 kB | 1136 kB | 43% | 2704 kB 
public   | param_mapping   | 1472 kB | 832 kB | 37% | 2304 kB 
archive  | supplie_price   | 944 kB | 896 kB | 49% | 1840 kB 
public   | product_param_param_id | 0 bytes | 1552 kB | 100% | 1552 kB 
archive  | product_param_id  | 0 bytes | 1536 kB | 100% | 1536 kB 

que he llegado a un punto donde no puedo ver el bosque por los árboles, y está empezando a ser un poco difícil de manejar.

Me pregunto si hay algo que pueda simplificarse o hacerse redundante. Las columnas no deben permanecer necesariamente iguales si la consulta puede hacerse mucho más simple.

+0

Vea también http://stackoverflow.com/questions/2596624/how-do-you-find-the-disk-size-of-a-postgres-postgresql- table-and-its-indexes. – Vadzim

Respuesta

3

consigo resultados comparables (con un formato diferente) con la siguiente consulta:

select 
    nspname as schema, 
    relname as name, 
    pg_relation_size(pg_class.oid) as size, 
    pg_indexes_size(pg_class.oid) as index, 
    pg_total_relation_size(pg_class.oid) as total, 
    100 * case when relkind = 'i' then pg_relation_size(pg_class.oid) 
            else pg_indexes_size(pg_class.oid) end 
     /pg_total_relation_size(pg_class.oid) as i_ratio 
from 
    pg_class 
    join pg_namespace on relnamespace = pg_namespace.oid 
order by 5 desc 
+0

Aunque sin bonita impresión. :-( –

+0

@AdamLindberg Puede agregar bastante impresión a la consulta con bastante facilidad. Mi punto clave de investigación fue la simplificación de las cosas para unir y las cosas de la subconsulta. –

+0

El único problema es que ordena después de órdenes 'pg_size_pretty (...)' basado en el valor de cadena del tamaño bonito, por lo tanto, 96 Kb> 960 Kb. –

0

En primer lugar, ¿por qué no utilizar los CTE para que el código sea más legible? Entonces usted no devuelve is_index por lo que parece estar redundunt

with p as (
SELECT nspname as schema, 
     relname as name, 
     pg_relation_size(nspname || '.' || relname) as s, 
     pg_total_relation_size(nspname || '.' || relname) as st 
    FROM pg_class 
     JOIN pg_namespace 
      ON (relnamespace = pg_namespace.oid) 
), 
pp as (
SELECT *, 
     case when st = s then 0 else s end as size, 
     case when st = s then s else st-s end as index 

    FROM p 
) 
select schema, 
     name, 
     pg_size_pretty(size) as size,   
     pg_size_pretty(index) as index, 
     (case st 
      when 0 then 0 
      else index*100/st 
     end) || '%' ratio, 
     st total 
from pp 
order by st desc limit 30; 
+0

No es realmente más simple o más corto, IMO. –

+0

Puede que tenga razón, pero parece ser más fácil de entender. Lo he cambiado un poco más. – quzary

1

Todo lo que realmente quiero hacer es señalar que La respuesta de quzary debe ser usar oid's y no crear cadenas que no puedan ser analizadas nuevamente a oid's.

Ahora tengo que escribir una entrada adecuada (tal vez este es el punto de detener los novatos de comentar?) Aquí hay otra versión limpia y prettied:

WITH p AS (
    SELECT n.nspname AS schema, 
     c.relname AS name, 
     pg_relation_size(c.oid) AS s, 
     pg_total_relation_size(c.oid) AS st 
    FROM pg_class c, pg_namespace n 
    WHERE c.relnamespace = n.oid 
) 
SELECT schema, name, 
    pg_size_pretty(s) AS size,   
    pg_size_pretty(st - s) AS index, 
    (100.0 * s/NULLIF(st, 0))::numeric(10,1) AS "% data of total", 
    st AS total 
FROM p 
ORDER BY st DESC 
LIMIT 30; 

en cuenta que puede ser útil añadir en la línea siguiente:

AND c.relkind = 'r' 

en el WHERE cláusula de p. Eso lo limitará solo a relaciones/tablas y hace que el código sea útil para un resumen general de tamaños de tabla.

0

¡Y no olvide que pg_relation_size y pg_total_relation_size no distinguen entre mayúsculas y minúsculas!

pg_relation_size(nspname || '.' || relname) 

en realidad debería ser:

pg_relation_size('"' || nspname || '.' || relname || '"') 

por lo que funciona con mayúsculas también. (Me tomó un tiempo resolver esto)

Cuestiones relacionadas