From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Status of the table access method work |
Date: | 2019-04-10 17:32:16 |
Message-ID: | 20190410173216.aoqtbmv5bbidqhyl@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-04-10 17:39:00 | Re: pgbench - add minimal stats on initialization |
Previous Message | Alexander Korotkov | 2019-04-10 17:14:17 | Re: Status of the table access method work |