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

From Gokulakannan Somasundaram
Subject Re: A thought on Index Organized Tables
Date
Msg-id 9362e74e1002260036m7f0795bfh9bea5839f9187905@mail.gmail.com
Whole thread Raw
In response to Re: A thought on Index Organized Tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A thought on Index Organized Tables  (Karl Schnaitter <karlsch@gmail.com>)
List pgsql-hackers
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt0pt 0.8ex; padding-left: 1ex;"> To be a bit more concrete: the typical sort of failure that you could<br /> get from
brokenbtree operators is failure of transitivity, that is<br /> the comparators report A < B and B < C for some
A,B, C, but do not say<br /> that A < C when those two values are compared directly.  I don't see any<br />
convenientway to detect that as a byproduct of normal index operations,<br /> because you wouldn't typically have a
reasonto make all three<br /> comparisons in close proximity.  Indeed, the searching and sorting<br /> algorithms do
theirbest to avoid making "redundant" comparisons of that<br /> kind.<br /></blockquote></div><br />This is interesting
Tom,but i am unable to understand, why it won't affect the current indexes. While insertion it might get inserted in a
blockand offset, and while searching it might either return no results / show a wrong place. Because ordering is
requiredfor searching also right? I definitely feel, i am missing something here.<br /><br />Gokul.<br /> 

pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Hot Standby query cancellation and Streaming Replication integration
Next
From: Piyush Newe
Date:
Subject: Correcting Error message