Martijn van Oosterhout <kleptog@xxxxxxxxx> writes: > If someone wants to step up and write the code, well... Bit hard, it > means that everytime a row is updated the index needs to be updated > too, gotta get all the corner cases, locking, etc. Even if someone did step up and write the code, the patch would probably be rejected. Copying row commit data into index entries would have some serious negative effects: * Index bloat. It would add probably 20 bytes to the size of an index entry, which is a lot (it would double the size of an index on a simple integer column, for instance). * Extra time and extra I/O to update these additional copies. Not only do we have to write the index changes themselves, but we'd have to make WAL log entries about each one (since the WAL replay environment is not nearly bright enough to find index entries for itself). That's expensive. The second point makes any such change a sure loser for an update-heavy database. In a nearly-read-only database, it might possibly be a winner, but in view of the index bloat problem it's not a sure thing even then. In short: this has been discussed and rejected before. Many times. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
