Martijn van Oosterhout <kleptog@svana.org> 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
