Re: Progress indication prototype

On Fri, Sep 17, 2010 at 4:50 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tor, 2010-09-16 at 19:14 -0400, Robert Haas wrote:
>> I think that there should be a function which returns just this one
>> piece of data and is not automatically called as part of select * from
>> pg_stat_activity.  Then we could eventually decide to give backends a
>> way to know if that function had been invoked on them and how
>> recently.
>
> Displaying this as part of pg_stat_activity is completely trivial: it's
> just displaying the value of a float variable.
>
> It seems you are advocating a completely different architecture, where
> someone can find out on demand what the progress or status of another
> session is, without that other session having known about that request
> before it started its current command.  But that seems pretty outlandish
> to me, and I would ask for more details on what you have in mind.

What you just said is about what I had in mind.  I admit I can't
articulate a more detailed design right off the top of my head, but
the architecture you're proposing seems dead certain to never cover
more than 0.1% of what people actually do.  If there's not even an
obvious way of generalizing this to the case of a full-database
VACUUM, let alone actual queries, that seems like a strong hint that
it might be badly designed.  Leaving some parts of the problem for
future development is perfectly reasonable, but there should be some
realistic hope that the next guy will be able to make some further
progress.

It seems to me that this is the sort of information that people will
normally never see, and therefore won't be willing to pay a
performance penalty for.  But when they need it (because something is
running long) they'll be happy to pay a modest penalty to get it.
Which is good, because the chances that we'll be able to provide this
information "for free" seem very poor even for utility commands.  But
it also means that we shouldn't carve the "can get this for free"
aspect of it into stone.

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