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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
