Skip site navigation (1) Skip section navigation (2)

Re: A thought on Index Organized Tables

From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Karl Schnaitter <karlsch(at)gmail(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-27 05:42:41
Message-ID: 9362e74e1002262142h489654cduce1cab9e7d3f9e37@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
>
>
> Actually Tom, i am not able to understand that completely. But what you are
> saying that in the current scenario, when there is a broken data type based
> index, then it will return no results, but never will return wrong results.
> So never the update will corrupt the heap data. But i take it as you say
> (please, correct me, if  i am wrong).
> But even returning no results might lead to failures in unqiue checks.
> While i inserting, i try to check whether a particular data is already
> inserted and if it returns no results, then it will go ahead and insert the
> data assuming that the unique check has passed, while in reality it has
> failed.
>
> Wait a minute.  Bingo!!!!  So for unique checks we are already going to
> index from Heap. So it is the same thing i am doing with Thick index. So if
> we can trust our current unique checks, then we should trust the Thick
> index.
>
> Thanks Tom!!! for having this good conversation....
>
> I think this broken data type problem / volatile function issue has to be
> resolved for the current index, if we advocate to stop the thick index.
> WOW!!!
>
>
> Can i get a feedback from Tom / Heikki regarding my observation?

Regards,
Gokul.

In response to

Responses

pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2010-02-27 06:08:39
Subject: Re: Correcting Error message
Previous:From: Greg SmithDate: 2010-02-27 05:10:50
Subject: Re: Lock Wait Statistics (next commitfest)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group