Re: Pluggable storage

On Sun, Jul 16, 2017 at 3:58 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> I strongly agree. I simply don't understand how you can adopt UNDO for
> MVCC, and yet expect to get a benefit commensurate with the effort
> without also implementing "retail index tuple deletion" first.
> Pursuing UNDO this way has the same problem that WARM likely has -- it
> doesn't really help with the worst case, where users get big,
> unpleasant surprises. Postgres is probably the only major database
> system that doesn't support retail index tuple deletion. It's a basic
> thing, that has nothing to do with MVCC. Really, what do we have to
> lose?
>

I think that "retail index tuple deletion" is the feature which could give
us some advantages even independently from pluggable storages. For
example, imagine very large table with only small amount of dead tuples.
In this case, it would be cheaper to delete index links to those dead
tuples one by one using "retail index tuple deletion", rather than do full
scan of every index to perform "bulk delete" of index tuples. One may
argue that you shouldn't do vacuum of large table when only small amount of
tuples are dead. But in terms of index bloat mitigation, very aggressive
vacuum strategy could be justified.

I agree with Robert that being able to store an arbitrary payload as a
> TID is probably not going to ever work very well.

Support of arbitrary payload as a TID doesn't sound easy. However, that
doesn't mean it's unachievable. For me, it's more like long way which could
be traveled step by step. Some of our existing index access methods
(B-tree, hash, GiST, SP-GiST) may support arbitrary payload relatively
easy, because they are not relying on its internal structure. For others
(GIN, BRIN) arbitrary payload is much harder to support, but I wouldn't say
it's impossible. However, if we make arbitrary payload support an option
of index AM and implement this support for first group of index AMs, it
would be already great step forward. So, for sample, it would be possible
to use indirect indexes when primary key is not 6-bytes, if index AM
supports arbitrary payload.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company