PostgreSQL – Meaning of n_live_tup and n_dead_tup in pg_stat_user_tables

postgresql

What is the meaning of n_live_tup and n_dead_tup in pg_stat_user_tables or pgstattuple?

Best Answer

Those two columns are the result of

SELECT pg_stat_get_live_tuples(c.oid) AS n_live_tup
     , pg_stat_get_dead_tuples(c.oid) AS n_dead_tup
FROM   pg_class c;

Representing the number of live and dead rows (tuples) in the table.
Find those functions in the manual.

Dead rows are deleted rows that will later be reused for new rows from INSERTs or UPDATEs (the space, not the data). Some dead rows (or reserved free space) can be particularly useful for HOT updates (Heap-Only Tuples) that can reuse space in the same data page efficiently. More on H.O.T.:

PostgreSQL Initial Database Size
Release notes for PostgreSQL 8.3 where this feature was introduced.

Or dead rows may be removed by VACUUM FULL (or plain VACUUM if it gets lucky) or similar operations on the table, thereby shrinking the physical table accordingly.

Whenever a row is deleted or updated, the old row version becomes invisible to all other transactions starting after the transaction has been committed. The row is completely dead as soon as there are no more uncommitted older transactions. That is necessary for PostgreSQL's MVCC model to handle concurrency.

Those are just statistics. You need to enable statistics collection in postgresql.conf if you want them to be updated automatically. track_counts should be on by default, though. Bear in mind that statistics are not updated instantaneously. Read more about that in the manual.

Related Solutions

Postgresql – Special syntax sth.name() in the CREATE FUNCTION statement, what does it mean

It's the name of a schema.
In other words, a schema-qualified function name. Just like you can schema-qualify tables or views or types or even operators (you just don't have to, normally).

Also learn about the schema search_path.

PostgreSQL – What is the Meaning of WAL File Name?

WAL file naming is really an implementation detail. See the source code - starting with the implementation of pg_xlogfile_name in src/backend/access/transam/xlogfuncs.c, which uses XLogFileName in src/include/access/xlog_internal.h:

#define XLogFileName(fname, tli, logSegNo)  \
    snprintf(fname, MAXFNAMELEN, "%08X%08X%08X", tli,       \
             (uint32) ((logSegNo) / XLogSegmentsPerXLogId), \
             (uint32) ((logSegNo) % XLogSegmentsPerXLogId))

From there you can see that in current PostgreSQL versions the archive name is eight zero-padded hex digits of timeline ID, then a somewhat oddly formatted value for the segment that works out to the high 32 bits of a 64-bit segment number zero-padded out to 8 hex digits, then the low 32 bits zero padded out to 8 hex digits. That format is really a historical quirk.

You can work that out because of the definition of XLogSegmentsPerXLogId:

#define XLogSegmentsPerXLogId   (UINT64CONST(0x100000000) / XLOG_SEG_SIZE)

which is 1 << 32 i.e. 2^32, so really the XLogFileName is just taking the high and low 32 bits.

That said, you shouldn't need to do anything with WAL based on the file names, except use them to uniquely identify a WAL file, so I'm wondering why you're asking this. What're you trying to achieve?

Best Answer

Related Solutions

Postgresql – Special syntax sth.name() in the CREATE FUNCTION statement, what does it mean

PostgreSQL – What is the Meaning of WAL File Name?

Related Question