Re: Reducing tuple overhead

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Reducing tuple overhead
Дата
Msg-id CA+TgmoaDjD061xe5aFoXQuONKszqkVu=R0vFsO2iy-tkwOBk-A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reducing tuple overhead  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Reducing tuple overhead  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Apr 30, 2015 at 12:31 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think I am missing something here, but when this second
> evaluation is needed.  Basically what I understand from index
> insertion is that it evaluates the value to be inserted in index
> before calling nbtree module and then nbtree just inserts the
> value/tuple passed to it.

Sure, but what happens if it doesn't evaluate to the same value?

Consider a tuple where a = 1 and a function f(a).  You insert the
tuple, evaluate f(a), and get 17.  So you insert an index tuple into
the btree with a value of 17, pointing at the tuple.  Now you delete
the tuple, evaluate f(a) again, and this time you get 42.  You search
the btree for an index tuple with a value of 42, and you don't find
one.  But the index tuple is still there.

With the current approach, that doesn't happen, because we effectively
search the entire index for tuples pointing at the heap tuple we're
trying to get rid of.  The only problem with that is that it's
crushingly expensive when the index is large and the number of tuples
we're cleaning out is comparatively small.  But that's a big problem.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: alternative compression algorithms?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: CTE optimization fence on the todo list?