RE: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)
От | Hiroshi Inoue |
---|---|
Тема | RE: Scan by TID (was RE: [HACKERS] How to add a new build-in operator) |
Дата | |
Msg-id | 002401bf1457$fbcd28a0$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)
|
Список | pgsql-hackers |
> -----Original Message----- > From: Bruce Momjian [mailto:maillist@candle.pha.pa.us] > Sent: Tuesday, October 12, 1999 4:14 AM > To: Tom Lane > Cc: Hiroshi Inoue; pgsql-hackers > Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in > operator) > > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > > 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. > > > > Yes, new path type, new plan type, probably a new access method if > > you want to keep things clean in the executor, cost-estimation routines > > in the planner, etc. etc. > > > > Looks like a lot of work, and a lot of added code bulk that will > > have to be maintained. I haven't figured out why you think it's > > worth it... tids are so transient that I don't see much need for > > finding tuples by them... > > That's why I just suggested a more short-circuited option of snatching > tid oids from expressions, and doing a heap_fetch directly at that point > to avoid the index scan. Seems it could be done in just one file. > I have thought the way as Tom says and I have a prospect to do it. But it would take a lot of work. Where to snatch and return to(or exit from) planner/executor in your story ? Hiroshi Inoue Inoue@tpf.co.jp.
В списке pgsql-hackers по дате отправления: