Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)]
От | Bruce Momjian |
---|---|
Тема | Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)] |
Дата | |
Msg-id | 199910111910.PAA29986@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: Scan by TID (was RE: [HACKERS] How to add a new build-in operator) ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
> > TODO list updated. Seems the tid could be accessed directly, by > > checking the page list, and if it is valid, just going to the tid. I > > assume you are working on that issue, or do you need assistance? > > > > Yes,I have done a part of my story. > I would add new type of path and scan by which we are able to access > tids directly. > > I don't understand planner/executor stage well. > So I'm happy if someone could check my story. My guess is that you are going to have to hard-code something into the backend to handle non-scan lookup of this type specially. Normally, either there is an index lookup, or a sequential scan. In your case, you "know" the actual location of the row, or at least a request for a possible valid location. You could create a fake index that really doesn't exist, but returns a tid that exactly matches the requested tid, or you could have the code check for a specific TID type, and heap_fetch the desired row directly, rather than performing a sequential scan. See the developers FAQ on how to do a heap_fetch with a tid. You can also use <I>heap_fetch()</I> to fetch rows by blocknumber/offset. The block number/offset is the tid. Of course, you have to make sure the tid is valid. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: