From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead |
Date: | 2015-07-22 18:03:58 |
Message-ID: | CA+TgmoZOLyq_uX9HfvPPHbTqQVar-rMivCFBYSBdWi9m+_3YCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 21, 2015 at 4:06 PM, Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-07-22 18:05:41 | Re: Volatility of pg_xact_commit_timestamp() and pg_last_committed_xact() |
Previous Message | Alvaro Herrera | 2015-07-22 18:03:57 | Re: brin index vacuum versus transaction snapshots |