This involves a bit of juggling of options. Firstly this renames the existing argument personalisation (which dates back to 2016) to with_template, which better describes what it actually does.
Then this adds a new argument with_personalisation that, if set False (not the default) will defer the loading of the _personalisation db column.
_personalisation is generally the biggest field in a notifications row. The field is rarely used in bulk requests and including it (significantly) inflates the size of intermediate results in the query plan, increasing the size of e.g. external sorts. Omitting it will probably also reduce the amount postgres needs to fetch from its TOAST table.
I'd also be interested in changing the service.get_all_notifications_for_service view to omit the personalisation in responses to deliver a similar optimization for a greater number of calls. However that would involve an interface change so I've not done it here.
FWIW, this may not deliver a significant visible speedup for this view itself, but it should reduce the amount it contributes to database cache pollution.
This involves a bit of juggling of options. Firstly this renames the existing argument
personalisation(which dates back to 2016) towith_template, which better describes what it actually does.Then this adds a new argument
with_personalisationthat, if setFalse(not the default) will defer the loading of the_personalisationdb column._personalisationis generally the biggest field in anotificationsrow. The field is rarely used in bulk requests and including it (significantly) inflates the size of intermediate results in the query plan, increasing the size of e.g. external sorts. Omitting it will probably also reduce the amount postgres needs to fetch from its TOAST table.I'd also be interested in changing the
service.get_all_notifications_for_serviceview to omit the personalisation in responses to deliver a similar optimization for a greater number of calls. However that would involve an interface change so I've not done it here.FWIW, this may not deliver a significant visible speedup for this view itself, but it should reduce the amount it contributes to database cache pollution.