agora inbox for [email protected]  

help / color / mirror / Atom feed

From: Jim Nasby <[email protected]>
To: Robert Haas <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Petr Jelinek <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: hlinnaka <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Sawada Masahiko <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Jeff Janes <[email protected]>
Subject: Re: Reducing tuple overhead
Date: Wed, 29 Apr 2015 17:29:31 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoYDKC0GLr42U0Xrha0ChTua29dCAr_kVXn=X8EeEDQ-0g@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAA4eK1+R2f+woEsu_Woj6AgoZE6LRxYCVg5kXiC3snKSkxHmFQ@mail.gmail.com>
	<[email protected]>
	<CAA4eK1KbqMicXYFo6MCp7nnOfjkuqyx071c+sAm0c+ftAKSCBw@mail.gmail.com>
	<[email protected]>
	<CA+TgmoYDKC0GLr42U0Xrha0ChTua29dCAr_kVXn=X8EeEDQ-0g@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

On 4/29/15 12:18 PM, Robert Haas wrote:
> On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby <[email protected]> wrote:
>> 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.
>
> True.  But I guess what I don't understand is: how big a deal is this,
> really?  The "uncorrupted" index can still return wrong answers to
> queries.  The fact that you won't end up with index entries pointing
> to completely unrelated tuples is nice, but if index scans are missing
> tuples that they should see, aren't you still pretty hosed?

Maybe, maybe not. You could argue it's better to miss some rows than 
have completely unrelated ones.

My recollection is there's other scenarios where this causes problems, 
but that's from several years ago and I wasn't able to find anything on 
a quick search of archives. I've wondered the same in the past and Tom 
had reasons it was bad, but perhaps they're overstated.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

view thread (27+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Reducing tuple overhead
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox