Hi!
Josh Berkus writes:
Now, if we had an OS which could be convinced to handle caching
differently for different physical devices, then I could see wanting
this setting to be per-tablespace. For example, it would make a lot of
sense not to FS-cache any data which is on a ramdisk or
Hi!
Thanks for your answer. Here is my general reasoning: I was thinking
about a way to use the profiler to determine the resource profile even
of (maybe even short time) business transactions. I would like to leave
the technical focus (high CPU usage, high I/O rate, too many disk sorts,
...)
Hi!
Itagaki Takahiro writes:
I updated Sampling profiler patch to be applied to HEAD cleanly.
[...]
Comments welcome.
I believe the profiler could give us a better understanding of where
different parts of the user visible response time originate from. The
problem with DTrace in my
Hi!
Tom Lane writes:
I'm not at all convinced that we should be putting effort into a
homegrown, partial substitute for DTrace.
In my opinion providing DTrace as the only means of profiling would
except a number of users from the tuning benefits. DTrace seems to rely
on specific kernel
