Hello,
I am running PostgreSQL 8.0.x on Solaris 10 AMD64. My Tablesize for this
test is about 80G. When I run a query on a column which is not indexed, I
get a full table scan query and that's what I am testing right now. (I am
artificially creating that scenario to improve that corner
Jignesh Shah [EMAIL PROTECTED] writes:
Running a script (available on my blog) I find the following top 5 functions
where it spends most time during a 10 second run of the script
It's pretty risky to draw conclusions from only 10 seconds' worth of
gprof data --- that's only 1000 samples total
Tom,
On 8/22/05 8:41 AM, Tom Lane [EMAIL PROTECTED] wrote:
MemoryContextSwitchTo and LockBuffer itself takes 15% of the total time of
the query. I was expecting read to be the slowest part (biggest component)
but it was way down in the 0.4% level.
You do know that gprof counts only CPU
Jignesh,
Also is there any way to optimize LockBuffer?
Yes, test on 8.1. The buffer manager was re-written for 8.1. You should
see a decrease in both LockBuffer and context switch activity.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Original Message Follows
From: Tom Lane [EMAIL PROTECTED]
To: Jignesh Shah [EMAIL PROTECTED]
CC: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] MemoryContextSwitchTo during table scan?
Date: Mon, 22 Aug 2005 11:41:40 -0400
Jignesh Shah [EMAIL PROTECTED] writes:
Running a script (available
Jignesh Shah wrote:
Now the question is why there are so many calls to MemoryContextSwitchTo
in a single SELECT query command? Can it be minimized?
I agree with Tom -- if profiling indicates that MemoryContextSwitchTo()
is the bottleneck, I would be suspicious that your profiling setup is
