Re: Reducing tuple overhead

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Reducing tuple overhead
Дата
Msg-id CAA4eK1KbqMicXYFo6MCp7nnOfjkuqyx071c+sAm0c+ftAKSCBw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reducing tuple overhead  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Reducing tuple overhead  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Reducing tuple overhead  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Apr 25, 2015 at 1:58 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>
> On 4/23/15 10:40 PM, Amit Kapila wrote:
>>
>> 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.
>
>
> I don't see how putting visibility at the page level helps indexes at all. We could already put XMIN in indexes if we wanted, but it won't help, because...
>

We can do that by putting transaction info at tuple level in index as
well but that will be huge increase in size of index unless we devise
a way to have variable index tuple header rather than a fixed.  

>> 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.
>
>
> ... which isn't possible. You can not go from a heap tuple to an index tuple.

We will have the access to index value during delete, so why do you
think that we need linkage between heap and index tuple to perform
Delete operation?  I think we need to think more to design Delete
.. by CTID, but that should be doable. 

> This has been discussed in the past.

I have tried to search in archive, but not getting what is the exact
problem.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Fwd: [GENERAL] 4B row limit for CLOB tables
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: adding more information about process(es) cpu and memory usage