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 199910121510.LAA20419@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > If we put something in the executor so when a sequential/index scan is
> > requested on a table that has a restriction on tid, you could just do a
> > heap_fetch and return the single row, rather than putting the query
> > through the whole scan process for every row checking to see if it
> > matches the WHERE restriction.
> 
> > Seems like a few lines in the executor could do the entire job of
> > fetching by tid by short-circuiting the sequential/index scan.
> 
> If I understand what you're proposing here, it would be a horrible
> mangling of the system structure and doubtless a fruitful source
> of bugs.  I don't think we should be taking shortcuts with this issue.
> If we think fast access by TID is worth supporting at all, we should
> expend the work to do it properly.

But to do that whole thing properly, you are adding tons of complexity
in access methods and stuff just to support one type that by definition
is very internal to the backend.

Just my ideas.  I understand you concern.  I just thought a few
well-placed lines could do the trick without adding tons of other stuff.


--  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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Dead CVS directories
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Features for next release