Robert Haas <robertmh...@gmail.com> writes:
> Oh, please, no. Gosh, this is supposed to be a lightweight facility!
> Just have a chunk of shared memory and write the data in there. If
> you try to feed this through the stats collector you're going to
> increase the overhead by 100x or more, and there's no benefit. We've
> got to do relation stats that way because there's no a priori bound on
> the number of relations, so we can't just preallocate enough shared
> memory for all of them. But there's no similar restriction here: the
> number of backends IS fixed at startup time. As long as we limit the
> amount of progress information that a backend can supply to some fixed
> length, which IMHO we definitely should, there's no need to add the
> expense of funneling this through the stats collector.
I agree with this, and I'd further add that if we don't have a
fixed-length progress state, we've overdesigned the facility entirely.
People won't be able to make sense of anything that acts much more
complicated than "0% .. 100% done". So you need to find a way of
approximating progress of a given command in terms more or less
like that, even if it's a pretty crude approximation.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
