Re: A thought on Index Organized Tables - Mailing list pgsql-hackers

From Karl Schnaitter
Subject Re: A thought on Index Organized Tables
Date
Msg-id d13967f91002240124m3e710947j2d8367e8ea564d5a@mail.gmail.com
Whole thread Raw
In response to Re: A thought on Index Organized Tables  (Gokulakannan Somasundaram <gokul007@gmail.com>)
Responses Re: A thought on Index Organized Tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 24, 2010 at 12:53 AM, Gokulakannan Somasundaram <gokul007@gmail.com> wrote:

Again not to deviate from my initial question, can we make a decision regarding unstable/mutable functions / broken data types ?


I second this question. A year or two ago, Gokul and I both proposed a feature that put visibility metadata into the index tuples and supported index-only scans, and the idea was dismissed because a user might choose incorrect ordering operators. I tried to ask for a clear explanation of the issue, but never got it.

Incorrect operators and mutable functions will surely lead to incorrect query results, but that is already a possibility with any index. It's also possible that a heap tuple is deleted, but the deletion is not recorded in the index because the tuple wasn't found. This is okay because (1) the heap tuple will remain where it is until vacuuming, and (2) during vacuuming, the visibility metadata in the index should be ignored when determining whether an index tuple points to a dead heap tuple. This ensures that all references to a heap tuple are removed before wiping it out.

The bottom line is that the visibility metadata is a good thing if you know when to trust it. It's fine to trust it when evaluating a SELECT. But not during a more dangerous operation like VACUUM.

Karl

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Fujii Masao
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Move documentation of all recovery.conf option to a new chapter.