Why is logging "slow"? On an empty transient table, inserting a single row took 50ms before changing it to UNLOGGED, 1ms afterwards.

Why is this exactly?  

If the table structure is necessary, I'll post it, but it's only five columns that normally total 500 bytes per row, a composite primary, and a composite unique.

If possible, can the performance cost be pinpointed to calculation or disk interaction?  If so, what percentage of the cost is due to each?
Crash-safe logged tables require at least two writes for every transaction:


A write to the write-ahead log (WAL) recording the data the server intends to write to the table; then
at some later stage, a write to the real table to apply the change.


The real write can occur after commit, but the WAL write must happen before the commit returns (unless synchronous_commit=off, which has data safety consequences).

To force that to happen PostgreSQL does an fsync(), which flushes the data written to WAL to disk. This operation takes time - on spinning magnetic hard drives it usually takes about one revolution; on an SSD it depends a lot on the amount of other data buffered for writing and on the erase block size etc. Either way, it can take some time.

Unlogged tables do not write to WAL. They just write into shared memory, and as shared memory fills up they write to the real table. No fsync() is done because unlogged tables aren't crash-safe.

To reduce the cost of commit flushes on logged tables you should batch your work into bigger transactions. Where the application allows, use asynchronous commit or enable a small commit delay to allow group commit.