Hi, On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote: > Your explanation of existing limitations looks very good and > convincing. But I think there is one you didn't mention. We require > new table AMs to basically save old "contract" between heap and > indexes. We have "all or nothing" choice during updates. So, storage > can either insert to none of indexes or insert to all of them > (HOT-like update).
I think that's a problem, and yea, I should have mentioned it. I'd earlier thought about it and then forgot. I however don't think we should design the interface for this before we have at least one AM that's actually in decent-ish shape that needs it. I seriously doubt we'll get the interface right enough. Note: I'm *extremely* *extremely* doubtful that moving the full executor invocations for expression indices etc into the tableam is a sane thing to do. It's possible to convince me there's no alternative, but it'll be really hard. I suspect the right direction will be more going in a direction of computing new index tuples for expression indexes before tableam gets involved. If we do that right, we can also implement the stuff that 1c53c4dec3985512f7f2f53c9d76a5295cd0a2dd reverted in a proper way. > I think any storage, which is going to address "write amplification" > point raised by Uber, needs to break this "contract". FWIW, I don't think it makes much point in using Uber as a justification for anything here. Their analysis was so deeply flawed and motivated by non-technical reasons that it should just be ignored. Greetings, Andres Freund
