I think this argument is a red herring ... or at least it leads in a direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current design, there is cause to do things as Magnus' original patch did.
We are already transmitting three more fields than necessary in every MsgHdr --- PID, database OID, and user ID --- and it will only get worse if we go down this path.
How about changing the statistics collector so that we only include a row in the statistics view when we receive the BESTART message? That would mean the BESTART message could include backend-start metadata (user ID, database ID, client address), and all other messages would only need enough header data to identify the backend process they are associated with (so perhaps backend id and process id).
Using the existing dead-backend hash table, we should be able to distinguish between the cases of "seen a message for a new backend before receiving its BESTART" and "seen a message for a dead backend after we've seen its BETERM".
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
