From: | David Lee <davidomundo(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)mail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Creating indexes in the background |
Date: | 2012-10-29 22:06:55 |
Message-ID: | 2D87615F-12B6-474C-8C53-9EA0EA0C6C6B@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> Since I've mentioned my use case, I might as well mention another issue I stumbled across, which is that concurrent index creation cannot happen from within trigger functions. I'm able to non-concurrently create indexes from within trigger functions. Why is there this disparity?
>
> Because concurrent index creation needs to open and commit transactions
> underneath, which regular index creation does not. Functions cannot run
> across transaction boundaries.
Would having background index creation allow for this? For example, launching a background concurrent index creation could record just the "actuation" of the index creation in the trigger's transaction, and postgresql would actually populate the index once the trigger's transaction is committed.
--David
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2012-10-29 22:07:03 | Re: [PATCH] Prefetch index pages for B-Tree index scans |
Previous Message | Dimitri Fontaine | 2012-10-29 21:30:40 | Re: Deparsing DDL command strings |