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
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 |