Re: monitoring CREATE INDEX [CONCURRENTLY]

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>, Rahila Syed <rahila(dot)syed(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: monitoring CREATE INDEX [CONCURRENTLY]
Date: 2019-03-29 20:07:42
Message-ID: CA+Tgmoa8yW__yGv87-_K=BKt-j0cNWGBYvY=c_wi=yhdE6KDFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 29, 2019 at 3:28 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> On 2019-Mar-29, Robert Haas wrote:
> > On Fri, Mar 29, 2019 at 2:16 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2019-03-29 20:30:09 Re: PostgreSQL pollutes the file system
Previous Message Joe Conway 2019-03-29 20:05:29 Re: PostgreSQL pollutes the file system