Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location
Дата
Msg-id CAGTBQpa5g5m=iFTGLQAuwJwNDJ8ugmzX38gzU8VRKap2f=Zw=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Mon, Jul 24, 2017 at 2:43 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Jul 24, 2017 at 10:13 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> Vacuum *might* be able to redistribute tuples too, while holding locks
>> to all 3 pages (the two children and the parent page), since it can
>> move the TID to the middle point of two actual child TIDs, mindlessly,
>> without checking to see if such TID actually exists - it just needs to
>> choose a TID cutoff point that will distribute item pointers evently.
>> I haven't tried this, but it is theoretically possible.
>
> I don't understand what you mean here. As long as the TIDs are a first
> class part of the keyspace, what VACUUM does or doesn't do should not
> matter. Page deletion stashes a TID in the highkey position of a leaf
> page within _bt_mark_page_halfdead(), but that shouldn't matter to
> you.
>
> I guess you're talking about contriving a TID value that is the mean
> of two real TID values -- the two that are on each side of the split
> point during a leaf page split. While that seems possible, I don't see
> much value in it. Unless you have normalized keys, you can only really
> truncate whole attributes. And, I think it's a bad idea to truncate
> anything other than the new high key for leaf pages, with or without
> normalized keys. Changing the keys once they're in internal pages is
> never going to be worth it.

That's what I'm saying. It might not be worth it. I haven't tested yet.



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] segfault in HEAD when too many nested functions call