Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > If backends store their current status in shared memory then a separate
> > process entirely can receive the interrupts, scan through the shared memory
> > process states and do the accounting.
>
> This sounds good until you think about locking. It'd be quite
> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
> this way, because of the overhead involved in taking and releasing
> spinlocks.
I'm not entirely convinced. The only other process that would be looking at
the information would be the statistics accumulator which would only be waking
up every 100ms or so. There would be no contention with other backends
reporting their info.
I was also thinking of reporting only basic information like which of a small
number of states the backend was in and which node of the plan is being
executed. If those are just integers then it might be possible to get away
without locking at all, storing them as sig_atomic_t.
I think there would still be a fair amount of cache coherency overhead like we
see with the tas instruction on Xeons but only if that backend's monitor block
is actually being touched by the statistics accumulator process which would
presumably be only when running an EXPLAIN ANALYZE or other tracing facility.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
