Thanks Tom, I think you're right. I just did an analyze on table test1 and the
execution plan now generated is more stable and predictable.
Thanks,
Suya
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, May 20, 2014 12:22 AM
To: Huang, Suya
Cc: pgsql-performan
On Thu, May 22, 2014 at 10:48 PM, Tom Lane wrote:
> Call graph data usually isn't trustworthy unless you built the program
> with -fno-omit-frame-pointer ...
This page is full of ideas as well:
https://wiki.postgresql.org/wiki/Profiling_with_perf
--
Michael
--
Sent via pgsql-performance mailin
Dimitris Karampinas writes:
> Is there any way to get the call stack of a function when profiling
> PostgreSQL with perf ?
> I configured with --enable-debug, I run a benchmark against the system and
> I'm able to identify a bottleneck.
> 40% of the time is spent on an spinlock yet I cannot find o
On 5/22/2014 7:27 AM, Dimitris Karampinas wrote:
Is there any way to get the call stack of a function when profiling
PostgreSQL with perf ?
I configured with --enable-debug, I run a benchmark against the system
and I'm able to identify a bottleneck.
40% of the time is spent on an spinlock yet I
Is there any way to get the call stack of a function when profiling
PostgreSQL with perf ?
I configured with --enable-debug, I run a benchmark against the system and
I'm able to identify a bottleneck.
40% of the time is spent on an spinlock yet I cannot find out the codepath
that gets me there.
Usi
