On Fri, Apr 24, 2015 at 1:03 AM, Jim Nasby <
Jim.Nasby@bluetreble.com> wrote:
>
> On 4/23/15 11:45 AM, Petr Jelinek wrote:
>>
>> On 23/04/15 18:24, Andres Freund wrote:
>>>
>>> Whether that's feasible complexity wise is debatable, but it's certainly
>>> possible.
>>>
>>>
>>> I do wonder what, in realistic cases, is actually the bigger contributor
>>> to the overhead. The tuple header or the padding we liberally add in
>>> many cases...
>>>
>>
>> The logical ordering patch + auto optimizations of column layout on
>> table creation/rewrite might help partially there.
>>
>> But what seems to be clear is that we need more in depth analysis of
>> what really contributes most to the tuple size in various use-cases and
>> then we can debate what we can do about it.
>
>
> Also, what Robert posted was that while we started at something like 15%-30% larger, we ended the test at 80% larger. That makes me think that the bigger win is not in reducing tuple size but tackling bloat.
>
I agree with you and what I think one of the major reasons of bloat is that
Index segment doesn't have visibility information due to which clearing of
Index needs to be tied along with heap. Now if we can move transaction
information at page level, then we can even think of having it in Index
segment as well and then Index can delete/prune it's tuples on it's own
which can reduce the bloat in index significantly and there is a benefit
to Vacuum as well. Now this has some downsides as well like Delete
needs to traverse Index segment as well to Delete mark the tuples, but
I think the upsides of reducing bloat can certainly outweigh the downsides.
In short, reducing the tuple size by moving transaction information at
page level can not only reduce the tuple size but can also help in
reducing bloat.
