Question: I am a python beginner going over a tutorial on neural networks and the PY torch module. I don't quite understand the behavior of this line. 

```
import torch.nn as nn

loss = nn.MSELoss()

print(loss)

>>MSELoss()

```

Since nn.MSELoss is a class, why does calling it to the variable loss not instantiate it as a class object? What type of code is in the class MSELoss that allows it to achieve this behavior?

Answer: 
As this subject doesn't seem to show up in the archives very much, I want to add a bit of detail before moving on. I asked related questions on several lists, forums, and by direct communication. Several people were kind enough to review the source code, provide historical background, and clear this up for me. Hopefully, leaving some detail here will help someone else down the track. Errors are all mine, obviously, corrections and enhancements more than welcome.

* Commit timestamps are assigned when the transaction's work is *completed*, but that's not the same was when it is *committed*. The WAL writer doesn't update the stamps to keep them in chronological sequence.
* Therefore, commit timestamps are **definitely** not a reliable mechanism for finding changes rows in order.
* Multiple clocks. Self-adjusting clocks. Oh the humanity!
* If you do want an in order-change sequence, logical decoding or replication are options. (I tried out logical replication a couple of weeks ago experimentally. Coolest. Thing. Ever.)
* The cost of timestamp tracking is 12 bytes per **transaction**, not per row. So, not so bad. (Timestamps are 8 bytes, transaction IDs are 4 bytes.)
* This is all part of the existing transaction system, so the realities of transaction ID rollaround apply here too. (Not scary in my case.) See:

<https://www.postgresql.org/docs/current/routine-vacuuming.html>
* For the record, you can enable this option on RDS via a parameter group setting. Just set track\_commit\_timestamp to 1 and restart. (The setting is 'on' in an postgres.conf.)
Lots of questions.

For a reference, the source code is in `src/backend/access/transam/commit_ts.c`.

1. I am not sure if it can be guaranteed that a later commit log sequence number implies a later timestamp. I would certainly not rely totally on it if the system clock can jump backwards due to time adjustments.
2. The timestamp is not stored in the row at all, but in the `pg_commit_ts` subdirectory of the data directory. Each record takes 10 bytes:

```c
/*
 * We need 8+2 bytes per xact.  Note that enlarging this struct might mean
 * the largest possible file name is more than 5 chars long; see
 * SlruScanDirectory.
 */
typedef struct CommitTimestampEntry
{
    TimestampTz time;
    RepOriginId nodeid;
} CommitTimestampEntry;

```

There is also information about commit timestamps in the transaction log so it can be recovered.
3. No index is needed, because the location of the timestamp is determined by the transaction number (each transaction has a fixed location for the commit timestamp). See `TransactionIdToCTsPage`.
4. Timestamps are kept as long as transaction numbers, if I understand the code correctly.
5. I can't tell what the overhead is, but it probably isn't huge.
6. Why should `VACUUM` or `VACUUM (FULL)` change the commit timestamp? That would be a bug.

Now that I understand what you want to achieve with commit timestamps, a word to that (I wish people would state the *real* question right away):

Commit timestamps are *not* the right tool for you. You could not index the expression, because `pg_xact_commit_timestamp` is not immutable.

Choose the simple and obvious solution and add an extra `timestamp with time zone` column with a `BEFORE` trigger that sets it to `current_timestamp` on `INSERT` and `UPDATE`. That can be indexed.

A famous man has said that premature optimization is the root of all evil.