Re: [HACKERS] ANALYZE command progress checker - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] ANALYZE command progress checker
Date
Msg-id 968b4eda-2417-8b7b-d468-71643cf088b6@openscg.com
Whole thread Raw
In response to Re: [HACKERS] ANALYZE command progress checker  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] ANALYZE command progress checker  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 3/10/17 1:06 PM, Andres Freund wrote:
> Hi,
>
> On 2017-03-10 02:11:18 -0600, Jim Nasby wrote:
>> Perhaps instead of adding more clutter to \dvS we could just have a SRF for
>> now.
>
> I don't see that as clutter, it's useful information, and keeping it
> discoverable is good, not bad.

If we keep adding status reporting commands at some point it's going to 
get unwieldy. Though, if they were in their own schema...

>> At over 2800 rows currently, you're not going to notice one more
>> addition to \dfS.
>
> I think it's hard to design a good SRF for this. Because the fields for
> different types of progress are different / empty, you can't just
> trivially return them as rows.  You'd have to do some EAV like
> 'command, field_name1, field_value1, ...' type of thing - not
> particularly pretty / easy to use.


Oh, I wasn't suggesting a single SRF for everything. Hopefully users 
will eventually figure out a good formula to drive a "progress bar" for 
each type of monitor, which is what you really want anyway (at least 99% 
of the time). If we got there we could have a single view that gave the 
% complete for every command that was providing feedback. If someone 
wanted details they could hit the individual SRF.
-- 
Jim Nasby, Chief Data Architect, OpenSCG
http://OpenSCG.com



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner
Next
From: "Joshua D. Drake"
Date:
Subject: [HACKERS] Should we eliminate or reduce HUP from docs?