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
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 |