On Tue, Mar 27, 2018 at 10:07 AM, Teodor Sigaev <teo...@sigaev.ru> wrote: > Storing number of attributes in now unused t_tid seems to me not so good > idea. a) it could (and suppose, should) separate patch, at least it's not > directly connected to covering patch, it could be added even before covering > patch.
I think that we should do that first. It's not very hard. > b) I don't like an idea to limiting usage of that field if we can do not > that. Future usage could use it, for example, for different compression > technics or something else. The extra status bits that this would leave within the offset field can be used for that in the future. >> * It makes diagnosing issues in the field quite a bit easier. Tools >> like pg_filedump can do the right thing (Tom mentioned pg_filedump and >> amcheck specifically). The nbtree IndexTuple format should not need to >> be interpreted in a context-sensitive way, if we can avoid it. > > Both pg_filedump and amcheck could correclty parse any tuple based on > BTP_LEAF flags and length of tuple. amcheck doesn't just care about the length of the tuple. It would have to rely on catalog metadata about this being an INCLUDE index. -- Peter Geoghegan
