Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead
Дата
Msg-id CA+TgmoZOLyq_uX9HfvPPHbTqQVar-rMivCFBYSBdWi9m+_3YCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Eliminating CREATE INDEX comparator TID tie-breaker overhead  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Tue, Jul 21, 2015 at 4:06 PM, Peter Geoghegan <pg@heroku.com> wrote:
> Design considerations and consequences
> --------------------------------------------------------

Good write-up.

> I'm not concerned about synchronized scans breaking my assumption of a
> physical ordering of heaptuples being fed to tuplesort.c. I think that
> it is unlikely to ever be worth seriously considering this case.

Why not?

> I have a hard time imagining anything (beyond synchronous scans)
> breaking my assumption that index tuplesorts receive tuples in heap
> physical order. If anything was to break that in the future (e.g.
> parallelizing the heap scan for index builds), then IMV the onus
> should be on that new case to take appropriate precautions against
> breaking my assumption.

I'm very dubious about that.  There are lots of reasons why we might
want to read tuples out of order; for example, suppose we want a
parallel sequential scan to feed the sort.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Alpha2/Beta1
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: brin index vacuum versus transaction snapshots