currently the bandwidth is one of the more expensive costs of stdb.
part of that is that deleted rows are send as full row even if the PK alone would be enough for the client.
for high update rate tables, this means it is sending almost double the data than it should be.
for row updates, it wouldn't even need the delete row at all as the client can just check if it has the pk in local cache and generate the update callback with just the new insert row.
so in short:
- deleted rows with PK could just be the PK
- updated rows with PK could just be the new insert row and no deleted row.
- rows without PK would still need to be send in full
but still this would likely cut down the bandwidth by close to 50% with just that small change.
Requested by @xDovos via the SpacetimeDB site.
currently the bandwidth is one of the more expensive costs of stdb.
part of that is that deleted rows are send as full row even if the PK alone would be enough for the client.
for high update rate tables, this means it is sending almost double the data than it should be.
for row updates, it wouldn't even need the delete row at all as the client can just check if it has the pk in local cache and generate the update callback with just the new insert row.
so in short:
but still this would likely cut down the bandwidth by close to 50% with just that small change.
Requested by @xDovos via the SpacetimeDB site.