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