From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | [DOC] Document concurrent index builds waiting on each other |
Date: | 2019-09-18 17:51:00 |
Message-ID: | CAAaqYe994=PUrn8CJZ4UEo_S-FfRr_3ogERyhtdgHAb2WG_Ufg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In my experience it's not immediately obvious (even after reading the
documentation) the implications of how concurrent index builds manage
transactions with respect to multiple concurrent index builds in
flight at the same time.
Specifically, as I understand multiple concurrent index builds running
at the same time will all return at the same time as the longest
running one.
I've attached a small patch to call this caveat out specifically in
the documentation. I think the description in the patch is accurate,
but please let me know if there's some intricacies around how the
various stages might change the results.
James Coleman
Attachment | Content-Type | Size |
---|---|---|
create-index-concurrently-docs-v1.patch | application/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-09-18 18:01:19 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |
Previous Message | Robert Haas | 2019-09-18 17:48:06 | backup manifests |