On Wed, Apr 10, 2019 at 8:32 PM Andres Freund <andres@anarazel.de> wrote:
> 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.
Sure.
My point is that once we get first table AM which needs this, say
zheap, we shouldn't make it like this
TM_Result (*tuple_update) (Relation rel, ... bool *update_indexes,
bool *delete_marking);
but rather try to design proper encapsulation of logic inside of table AM.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company