On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: >> If the use case for this is to gather instrumentation, I'd suggest calling >> the hook in RetrieveInstrumentation, and calling it appropriately. It would >> make the intended use far clearer than it is now. >> >> And if it saves some work, all the better. >> >> Until there's a use case for a non-instrumentation hook in that place, I >> wouldn't add it. This level of generality sounds like a solution waiting >> for a problem to solve. >> > The use cases I'd like to add are extension specific but significant for > performance analytics. These statistics are not included in Instrumentation. > For example, my problems are GPU execution time, data transfer ratio over > DMA, synchronization time for GPU task completion, and so on. > Only extension can know which attributes are collected during the execution, > and its data format. I don't think Instrumentation fits these requirements. > This is a problem I faced on the v9.6 based interface design, so I could > notice it.
What RetrieveInstrumentation currently does may not cover the extension's specific instrumentation, but what I'm suggesting is adding a hook, like the one you're proposing for ParallelFinish, that would collect extension-specific instrumentation. Couple that with extension-specific explain output and you'll get your use cases covered, I think. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
