Re: proposal: be smarter about i/o patterns in index scan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: be smarter about i/o patterns in index scan
Дата
Msg-id 20357.1084998680@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: be smarter about i/o patterns in index scan  ("Jeffrey W. Baker" <jwbaker@acm.org>)
Список pgsql-hackers
"Jeffrey W. Baker" <jwbaker@acm.org> writes:
> No doubt, you can't just naively create giant vectors of TIDs and expect
> to sort them.  Is there any concept in Pg of an unrealized result?

Only for the case of a partially-read plan result.  That is, we do this
for rowsets, but not for scalars or arrays.  A lot of the point of the
LIMIT 1 example is that it is exploiting the fact that we won't ever
materialize the full output of the indexscan.

> If you scanned an index building up a result set that was totally
> unrealized, except for the TID and the index columns, you could
> cheaply join two such results without ever touching the heap.  You
> could also use the existing Sort execution step to sort such a result.
> Then don't touch the heap something accesses a non-index column, or
> because you are returning the result somewhere and need to satisfy
> MVCC visibility limits.

This is basically what I was talking about with IndexOnlyScan/TidExpand.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jeffrey W. Baker"
Дата:
Сообщение: Re: proposal: be smarter about i/o patterns in index scan
Следующее
От: Greg Stark
Дата:
Сообщение: Re: proposal: be smarter about i/o patterns in index scan