A thought on Index Organized Tables
in [PgSql]
|
Prev: [COMMITTERS] pgsql: Oops, don't forget to rewind the directory before scanning it to
Next: Time travel on the buildfarm
From: Gokulakannan Somasundaram on 25 Feb 2010 23:24 > No, it's far from harmless. As soon as that heap TID gets filled with > an unrelated tuple, you run the risk of indexscans alighting on and > perhaps modifying the wrong tuple. > > Tom, 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? Thanks, Gokul.
From: Gokulakannan Somasundaram on 25 Feb 2010 23:33 On Fri, Feb 26, 2010 at 9:54 AM, Gokulakannan Somasundaram < gokul007(a)gmail.com> wrote: > > No, it's far from harmless. As soon as that heap TID gets filled with >> an unrelated tuple, you run the risk of indexscans alighting on and >> perhaps modifying the wrong tuple. >> >> > Tom, i think this will never happen. The only issue is when we need to go back to the index from heap. This is to update the timestamps of update/delete. Gokul.
From: Tom Lane on 25 Feb 2010 23:47 Gokulakannan Somasundaram <gokul007(a)gmail.com> writes: >> Actually, if you need to squeeze a few more bits into that word, the >> thing to do would be to get rid of storing the tuple length there. >> This would involve adding the same type of indirection header that >> we use for HeapTuples, so that the length would be available at need >> without going back to the item pointer. I > I feel the other one is easy. To store the hint bits inside the ItemId, in > the place of size. No, we're not going there. That breaks the fundamental page content manipulation algorithms, and falls down for tuples not yet stored in a page (or being examined without a pointer to the page readily at hand), and has no redeeming social value anyway compared to doing it in the proven fashion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 Feb 2010 23:59 Gokulakannan Somasundaram <gokul007(a)gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Gokulakannan Somasundaram on 26 Feb 2010 01:09
> No, we're not going there. That breaks the fundamental page content > manipulation algorithms, and falls down for tuples not yet stored in a > page (or being examined without a pointer to the page readily at hand), > and has no redeeming social value anyway compared to doing it in the > proven fashion. > > Tom, I was also concerned regarding that, but just thought of informing you about the option. But i think it will never fall down for tuples not stored in the page. As we have the offset and the hint bits to mention whether a tuple is there or not. Only the two byte size field will move down by my suggestion. But your intuition has the most probability of success. My concern was that it would make the page of a heap different from page of a b-tree index. Gokul. |