PostgreSQL has an optimization called HOT that reduces the cost of updates in an MVCC environment.
For it to work, the columns that are being updated cannot be indexed.
History-free RelStorage will update existing rows when objects change, but one of the columns updated is the associated transaction ID. That column is indexed, making us ineligible for this optimization.
It would be interesting to know how much of a difference this optimization makes in benchmarks. It's possible that we rarely use that index (off hand, I think it may be mostly used for iteration, which is rare?). If the benchmarks show significant improvements, it may be worth dropping if we can confirm that it is rarely used.
At the least, this should be documented as knowing that HOT isn't used can help in capacity planning.
PostgreSQL has an optimization called HOT that reduces the cost of updates in an MVCC environment.
For it to work, the columns that are being updated cannot be indexed.
History-free RelStorage will update existing rows when objects change, but one of the columns updated is the associated transaction ID. That column is indexed, making us ineligible for this optimization.
It would be interesting to know how much of a difference this optimization makes in benchmarks. It's possible that we rarely use that index (off hand, I think it may be mostly used for iteration, which is rare?). If the benchmarks show significant improvements, it may be worth dropping if we can confirm that it is rarely used.
At the least, this should be documented as knowing that HOT isn't used can help in capacity planning.