PostgreSQL: COUNT (*) usa un escaneo secuencial, no un índice

¿Por qué PostgreSQL escanea secuencialmente la tabla en busca de COUNT(*)consultas, mientras que hay una clave primaria muy pequeña e indexada?

postgresql index count

— Adam Matan
fuente

Las páginas wiki oficiales dan una respuesta a eso:

[...] La razón por la cual esto es lento está relacionada con la implementación de MVCC en PostgreSQL. El hecho de que varias transacciones puedan ver diferentes estados de los datos significa que no puede haber una forma directa para que "COUNT (*)" resuma los datos en toda la tabla; PostgreSQL debe recorrer todas las filas, en cierto sentido. Esto normalmente da como resultado una lectura de exploración secuencial sobre cada fila de la tabla. [...]

Además, puede probar un ANÁLISIS para reconstruir la información para el planificador de consultas.

Debería obtener un mejor rendimiento utilizando, COUNT(an uniquly indexed field)pero si esto es muy grande, un escaneo seq es la única forma de hacerlo.

Si necesita números muy rápidos y no tiene miedo de consultar el esquema, puede hacer lo siguiente

SELECT reltuples FROM pg_class WHERE oid = 'your_table'::regclass

Pero no confíe en estos valores, ya que solo es un número "estimado" (aunque a menudo exacto) de tuplas en la tabla.

— DrColossos
fuente

No creo que esto sea correcto. No he leído nada en ningún lado, donde COUNT(pk)mejorará el rendimiento. Creo que siempre va a hacer una exploración ss-

— vol7ron

Sin una cláusula where que sea correcta, se realizará una exploración secuencial. Con una cláusula where select select postgresql PUEDE usar un índice, pero tenga en cuenta que VOLVERÁ a la tabla para verificar la visibilidad de las tuplas sobre las que informa.

— Scott Marlowe