Re: Reducing tuple overhead

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, hlinnaka <hlinnaka(at)iki(dot)fi>, Bruce Momjian <bruce(at)momjian(dot)us>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Reducing tuple overhead
Date: 2015-04-30 13:46:19
Message-ID: CAA4eK1Lh7VREqbfufSiVdghKUwo69MFc--Th=KvhQZKUrKcpWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 30, 2015 at 5:03 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Apr 30, 2015 at 12:31 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.

As the index expression contain table columns and all the functions
or operators used in expression must be IMMUTABLE, won't that
guarantee to avoid such a situation?

If not, then I think for such indexes we might need to search
for tupleoffset in the entire index and mark it as Delete or may be
for such indexes follow the current mechanism. I think it will still
give us lot of benefit in more common cases.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-04-30 13:54:34 Re: Reducing tuple overhead
Previous Message Pavel Stehule 2015-04-30 13:44:19 Re: Loss of some parts of the function definition