Pavan Deolasee wrote: > On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > > > Effectively, my idea is not to chill/break the HOT chains during index > > creation, but rather to abandon them and wait for VACUUM to clean them > > up. > > > > My idea is much closer to the idea of a bit per index on every tuple, > > except the tuple xmax and pg_index xid replace them. > > > > > > > Regarding waiting inside CREATE INDEX for transactions started > before us doesn't seem like a big problem to me. But may be I am > mistaken. > > Given a choice I won't complicate the fetch/update logic more. I would > rather fix the problem at hand, if I can. But I would go by the > community agreement on this issue since I don't have a clear > answer.
Yep, we all want is simple. If we can do the xid idea, we hopefully fix the concurrent index scan and crash recovery issues. > Also, I am wondering whether the information that which index is used to > fetch a tuple is always available. I haven't checked, but do we have that > information in lossy bitmap heapscan ? Oh, that is an interesting problem because an index might have one index entry representing an entire HOT chain, while another index might represent each chain member by individual index entries. When we do the bitmaps, don't we access them by heap tid, meaning we would find all entries anyway? -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
