Currently for the updated django entity that has an associated TriggerChannel the notification payload is sent via postgres NOTIFY and it contains the old and the new serialized entity states. In the listener the payload that is sent via postgres channel is used only to find the appropriate Notification record from the DB (by comparing the payload text) and then the payload is retrieved from the database record and is actually used.
This sending of the complete payload is suboptimal:
the serialized size of the record that can be sent is limited by the max payload size (8k) that postgres supports when sending via the channel. Given that both old and new records are sent that size is rather even smaller (<4k) for updates.
the serialized payload makes roundtrips from postgres to application (in the NOTIFY message) and then back to pg server (as a query parameter) and yet another time as a query result.
This MR implements sending only the notification ID in the postgres notification for the TriggerChannel that has a persistent notifications enabled.
This implementation keeps the listener backward compatible as in it can still process old notifications sent with a complete payload. That compatiblity should be removed in the followup versions.
This fixes https://github.com/PaulGilmartin/django-pgpubsub/issues/67
Currently for the updated django entity that has an associated TriggerChannel the notification payload is sent via postgres
NOTIFYand it contains the old and the new serialized entity states. In the listener the payload that is sent via postgres channel is used only to find the appropriateNotificationrecord from the DB (by comparing the payload text) and then the payload is retrieved from the database record and is actually used.This sending of the complete payload is suboptimal:
oldandnewrecords are sent that size is rather even smaller (<4k) for updates.NOTIFYmessage) and then back to pg server (as a query parameter) and yet another time as a query result.This MR implements sending only the notification ID in the postgres notification for the
TriggerChannelthat has a persistent notifications enabled.This implementation keeps the listener backward compatible as in it can still process old notifications sent with a complete payload. That compatiblity should be removed in the followup versions.