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 supe
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,
...) to
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 op
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 opti
