Re: monitoring CREATE INDEX [CONCURRENTLY] - Mailing list pgsql-hackers

From Robert Haas
Subject Re: monitoring CREATE INDEX [CONCURRENTLY]
Date
Msg-id CA+Tgmoa8yW__yGv87-_K=BKt-j0cNWGBYvY=c_wi=yhdE6KDFw@mail.gmail.com
Whole thread Raw
In response to Re: monitoring CREATE INDEX [CONCURRENTLY]  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: monitoring CREATE INDEX [CONCURRENTLY]
List pgsql-hackers
On Fri, Mar 29, 2019 at 3:28 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Mar-29, Robert Haas wrote:
> > On Fri, Mar 29, 2019 at 2:16 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > > I think we should consider a new column of an array type, where we could
> > > put things like the list of PIDs to be waited for, the list of OIDs of
> > > index to rebuild, or the list of partitions to build the index on.
> >
> > This has to work with a fixed-size chunk of shared memory.
>
> Bah, of course.
>
> Maybe we can consider using dynamic shmem for that, and include a
> pointer to it in the fixed-size chunk.  (It's a bit too late to be
> writing this code, mind; I'm just proposing this for a future
> improvement.)

Sounds expensive.  We don't want to spend a lot of energy pushing out
progress reports which, often enough, nobody will ever examine.  I
designed the current system as I did to make it cheap.  Adding DSM in
there would open up lots of exciting new failure possibilities and
significantly increase the overhead.  And probably add quite a bit of
code complexity, too.

There's probably room for an elaborate progress-reporting facility in
PostgreSQL that can even handle arbitrary stuff like queries.  But I
think it might look a lot different from this one, which is designed
and intended to handle simple cases.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: PostgreSQL pollutes the file system
Next
From: Christoph Berg
Date:
Subject: Re: PostgreSQL pollutes the file system