Tengo una tabla con muchas inserciones, estableciendo uno de los campos ( uploaded_at
) en NULL
. Luego, una tarea periódica selecciona todas las tuplas WHERE uploaded_at IS NULL
, las procesa y actualiza, estableciendo uploaded_at
la fecha actual.
¿Cómo debo indexar la tabla?
Entiendo que debería usar un índice parcial como:
CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL
O algo así. Sin embargo, estoy un poco confundido si es correcto indexar en un campo que siempre lo es NULL
. O si es correcto usar un índice b-tree. Hash parece una mejor idea, pero es obsoleto y no se replica a través de la replicación de espera en caliente. Cualquier consejo sería muy apreciado.
He experimentado un poco con los siguientes índices:
"foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL
"foo_part_id" btree (id) WHERE uploaded_at IS NULL
y el planificador de consultas parece elegir siempre el foo_part
índice. explain analyse
También produce un resultado ligeramente mejor para el foo_part
índice:
Index Scan using foo_part on t1 (cost=0.28..297.25 rows=4433 width=16) (actual time=0.025..3.649 rows=4351 loops=1)
Index Cond: (uploaded_at IS NULL)
Total runtime: 4.060 ms
vs
Bitmap Heap Scan on t1 (cost=79.15..6722.83 rows=4433 width=16) (actual time=1.032..4.717 rows=4351 loops=1)
Recheck Cond: (uploaded_at IS NULL)
-> Bitmap Index Scan on foo_part_id (cost=0.00..78.04 rows=4433 width=0) (actual time=0.649..0.649 rows=4351 loops=1)
Total runtime: 5.131 ms
fuente
id
campo en serie , por ejemplo?serial
es tan bueno como cualquiera. El punto es si realmente hay consultas para usarlo.