Re: Reducing tuple overhead

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-27 21:01:13
Message-ID: 553EA399.1010508@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/25/15 12:12 AM, Amit Kapila wrote:
> > ... 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.

The problem with just having the value is that if *anything* changes
between how you evaluated the value when you created the index tuple and
when you evaluate it a second time you'll corrupt your index. This is
actually an incredibly easy problem to have; witness how we allowed
indexing timestamptz::date until very recently. That was clearly broken,
but because we never attempted to re-run the index expression to do
vacuuming at least we never corrupted the index itself.

> > This has been discussed in the past.
>
> I have tried to search in archive, but not getting what is the exact
> problem.

Unfortunately I can't find prior discussion now either... :/
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-04-27 21:21:36 Re: Feedback on getting rid of VACUUM FULL
Previous Message Jim Nasby 2015-04-27 20:53:30 Re: PL/pgSQL, RAISE and error context