From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Remi Colinet <remi(dot)colinet(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH v2] Progress command to monitor progression of long running SQL queries |
Date: | 2017-05-16 18:07:09 |
Message-ID: | CABUevEzZ-L4devOwQArxHfbvwtfgisP7pXLSq+u5qk31dh3eqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 16, 2017 at 7:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, May 16, 2017 at 2:17 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > Perhaps DSM? It is not user-friendly to fail sporadically...
>
> Yeah. I've been thinking we might want to give each backend a
> backend-lifetime DSA that is created on first use. That could be
> useful for some parallel query stuff and maybe for this as well.
> Other backends could attach to it to read data from it, and it would
> go away on last detach (which would normally be the detach by the
> creating backend, but not if somebody else happens to be reading at
> the moment the backend exits).
>
That seems like a pretty good idea. I've been considering something simliar
for the usecase of being able to view the "collected but not sent yet"
statistics inside a backend (which tables have been accessed, number of
reads etc),and this seems like it could be used for that as well.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | amul sul | 2017-05-16 18:34:50 | Re: [POC] hash partitioning |
Previous Message | Alvaro Herrera | 2017-05-16 17:52:19 | Re: COPY FROM STDIN behaviour on end-of-file |