Now XC team finished table rebalancing feature by ALTER TABLE ... DISTRIBUTE BY ... statement. This runs with all the rows of the table locked. The next is to do this concurrently, not locking rows and run everything background. Different from other ALTER TABLE operation, this doesn't affect the logical view of the table and is safe to run this concurrently, as in the case of CREATE INDEX CONCURRENTLY.
To implement this, I thought to use a kind of log shipping for specific table. To choose WAL records for the target table and then send them to the handler. This looks very simple but we should consider TOAST as well. Some says that it's much simpler to implement this as a part of walsender. Yes, this can be if we don't have to worry about full page writes.
Full page writes are not simple to deal with. We have to extract logical operation from them. We can avoid this difficulty if the WAL filter is a part of XLogInsert(), which runs as each backend process and we need to handle this as well.
Which will be better?
To implement this, I thought to use a kind of log shipping for specific table. To choose WAL records for the target table and then send them to the handler. This looks very simple but we should consider TOAST as well. Some says that it's much simpler to implement this as a part of walsender. Yes, this can be if we don't have to worry about full page writes.
Full page writes are not simple to deal with. We have to extract logical operation from them. We can avoid this difficulty if the WAL filter is a part of XLogInsert(), which runs as each backend process and we need to handle this as well.
Which will be better?
No comments:
Post a Comment