On 7/22/15 9:15 AM, Robert Haas wrote:
>> I'm not proposing this feature, I'm merely asking for it to be defined in a
>> >way that makes it work for more than just VACUUM. Once we have a way of
>> >reporting useful information, other processes can be made to follow that
>> >mechanism, like REINDEX, ALTER TABLE etc.. I believe those things are
>> >important, even if we never get such information for user queries. But I
>> >hope we do.
>> >
>> >I won't get in the way of your search for detailed information in more
>> >complex forms. Both things are needed.
> OK.
>
> One idea I have is to create a system where we expose a command tag
> (i.e. VACUUM) plus a series of generic fields whose specific meanings
> are dependent on the command tag. Say, 6 bigint counters, 6 float8
> counters, and 3 strings up to 80 characters each. So we have a
> fixed-size chunk of shared memory per backend, and each backend that
> wants to expose progress information can fill in those fields however
> it likes, and we expose the results.
>
> This would be sorta like the way pg_statistic works: the same columns
> can be used for different purposes depending on what estimator will be
> used to access them.
If we want to expose that level of detail, I think either JSON or arrays
would make more sense, so we're not stuck with a limited amount of info.
Perhaps DDL would be OK with the numbers you suggested, but
https://www.pgcon.org/2013/schedule/events/576.en.html would not, and I
think wanting query progress is much more common.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com