Re: A thought on Index Organized Tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
Cc: 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-26 04:59:29
Message-ID: 16458.1267160369@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> writes:
> In the Function based indexes on those functions, which we are
> suspecting to be a volatile one Or in the datatypes, which we suspect to be
> broken, can we have additional checks to ensure that to ensure that this
> does not happen? I mean, do you think, that would solve the issue?

Proving that a set of comparison operators are consistent just by
examining their runtime behavior is probably equivalent to solving the
halting problem. I can't see us doing it, or wanting to accept the
overhead of checking it even if it could be done.

To be a bit more concrete: the typical sort of failure that you could
get from broken btree operators is failure of transitivity, that is
the comparators report A < B and B < C for some A, B, C, but do not say
that A < C when those two values are compared directly. I don't see any
convenient way to detect that as a byproduct of normal index operations,
because you wouldn't typically have a reason to make all three
comparisons in close proximity. Indeed, the searching and sorting
algorithms do their best to avoid making "redundant" comparisons of that
kind.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-26 05:11:56 Re: Avoiding bad prepared-statement plans.
Previous Message Tom Lane 2010-02-26 04:47:39 Re: A thought on Index Organized Tables