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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-02-27 06:08:39 | Re: Correcting Error message |
Previous Message | Greg Smith | 2010-02-27 05:10:50 | Re: Lock Wait Statistics (next commitfest) |