>> 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?
>
On 28 October 2012 01:20, David Lee wrote:
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creation in the background s
On Sun, Oct 28, 2012 at 8:22 AM, David Lee wrote:
> Thanks. Is this something viable as a feature request?
Just to contribute a tiny amount of data: I also get this request from
users on a semi-regular basis. It's definitely below the pains of
pg_dump/restore or fork-and-reuse-of-connections of l
On 10/28/12 10:22 AM, David Lee wrote:
Thanks. Is this something viable as a feature request?
Possibly, but it's not terribly high on the list.
In the meantime, we've built a user-space index daemon at $WORK that generally
solves this issue. We intend to release it at some point, but if you n
David Lee escribió:
> Thanks for all the responses.
>
> I forgot to ask in my initial post: If not already available, is background
> indexing a viable feature request? (This was why I sent to pgsql-hackers).
>
> My use case is a multi-tenant CMS where indexes can be created by a web
> front-en
On Oct 27, 2012, at 19:20, David Lee wrote:
> Hey folks,
>
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creation i
On Sat, Oct 27, 2012 at 4:20 PM, David Lee wrote:
> Hey folks,
>
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creatio
On Sun, Oct 28, 2012 at 8:20 AM, David Lee wrote:
> Hey folks,
>
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creation
On Sat, Oct 27, 2012 at 6:20 PM, David Lee wrote:
> Hey folks,
>
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creatio
David Lee wrote:
> It seems like right now when you want to create an index
> concurrently, the index creation will get canceled if you cancel
> the statement (i.e. you must keep your statement open).
>
> Is there a way to "launch" an index creation in the background so
> that the statement doesn
Thanks for all the responses.
I forgot to ask in my initial post: If not already available, is background
indexing a viable feature request? (This was why I sent to pgsql-hackers).
My use case is a multi-tenant CMS where indexes can be created by a web
front-end. Since web requests should retur
On Sat, Oct 27, 2012 at 7:20 PM, David Lee wrote:
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creation in the backgr
Thanks. Is this something viable as a feature request?
On Oct 28, 2012 7:48 AM, "David Johnston" wrote:
> On Oct 27, 2012, at 19:20, David Lee wrote:
>
> > Hey folks,
> >
> > It seems like right now when you want to create an index concurrently,
> the index creation will get canceled if you canc
Hey folks,
It seems like right now when you want to create an index concurrently, the
index creation will get canceled if you cancel the statement (i.e. you must
keep your statement open).
Is there a way to "launch" an index creation in the background so that the
statement doesn't need to be k
14 matches
Mail list logo
