Re: [HACKERS] Pluggable storage - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] Pluggable storage
Date
Msg-id CAPpHfduSCJEqL9oKoHnJ6pQNFV5044mETwmbdKPYzGBkbt9VQA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Pluggable storage  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [HACKERS] Pluggable storage
List pgsql-hackers
On Sun, Jul 16, 2017 at 3:58 AM, Peter Geoghegan <pg@bowt.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 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] segfault in HEAD when too many nested functions call
Next
From: Alik Khilazhev
Date:
Subject: Re: [HACKERS] [WIP] Zipfian distribution in pgbench