Hi,
Currently I'm using postgresql v8.1.3 and the latest jdbc.
I try to open a JReports' report and the time taken to completely open the
report is 137453ms.
Then I open the same report but this time I connect to postgresql v7.2.2
but the completion time is even faster than connect to
You usertime is way too high for T2000...
If you have a 6 core machine with 24 threads, it says all 24 threads are
reported as being busy with iostat output.
Best way to debug this is use
prstat -amL
(or if you are dumping it in a file prstat -amLc prstat.txt)
and find the pids with high
I have seen MemoryContextSwitchTo taking time before.. However I am not
sure why would it take so much CPU time?
Maybe that function does not work efficiently on Solaris?
Also I donot have much idea about slot_getattr.
Anybody else? (Other option is to use collect -p $pid experiments to
Hi,
I have a web page, that executes several SQLs.
So, I would like to know witch one of those SQLs consumes more CPU.
For example,
I have SQL1 that is executed in 1.2 secs and a SQL2 that is executed in
200 ms.
But SQL2 is executed 25 times and SQL1 is executed 1 time, so really
SQL2
On Tue, May 16, 2006 at 07:08:51PM -0700, David Wheeler wrote:
On May 16, 2006, at 18:29, Christopher Kings-Lynne wrote:
Yes, but there are definitely programming cases where memoization/
caching definitely helps. And it's easy to tell for a given
function whether or not it really helps
Here's a corner case that might interest someone. It tripped up one of our
programmers.
We have a table with 10 million rows. The ID column is indexed, the table
has been vacuum/analyzed. Compare these two queries:
select * from tbl where id = 1000 limit 1;
select * from tbl where
On 17 May 2006, at 16:21, Ruben Rubio Rey wrote:
I have a web page, that executes several SQLs.
So, I would like to know witch one of those SQLs consumes more CPU.
For example,
I have SQL1 that is executed in 1.2 secs and a SQL2 that is
executed in 200 ms.
But SQL2 is executed 25 times and
Please don't reply to previous messages to start new threads. This makes it
harder to find stuff in the archives and may keep people from noticing your
message.
On Wed, May 17, 2006 at 08:54:52 -0700,
Craig A. James [EMAIL PROTECTED] wrote:
Here's a corner case that might interest someone. It
Title: Performance/Maintenance test result collection
Hi.
I'm trying to plan for a performance test session where a large database is subject to regular hits from my application while both regular and full database maintenance is being performed. The idea is to gain a better idea on the
On Wed, 2006-05-17 at 08:54 -0700, Craig A. James wrote:
Here's a corner case that might interest someone. It tripped up one of our
programmers.
We have a table with 10 million rows. The ID column is indexed, the table
has been vacuum/analyzed. Compare these two queries:
select *
Bruno Wolff III [EMAIL PROTECTED] writes:
I suspect it wasn't intended to be a full table scan. But rather a sequential
scan until it found a matching row. If the data in the table is ordered by
by id, this strategy may not work out well. Where as if the data is randomly
ordered, it would be
Tom Lane wrote:
There is not anything in there that considers whether the table's
physical order is so nonrandom that the search will take much longer
than it would given uniform distribution. It might be possible to do
something with the correlation statistic in simple cases ...
In this
On Wed, May 17, 2006 at 08:54:52AM -0700, Craig A. James wrote:
Here's a corner case that might interest someone. It tripped up one of
our programmers.
We have a table with 10 million rows. The ID column is indexed, the
table has been vacuum/analyzed. Compare these two queries:
On Wed, May 17, 2006 at 01:50:22PM -0400, Chris Mckenzie wrote:
Hi.
I'm trying to plan for a performance test session where a large database is
subject to regular hits from my application while both regular and full
database maintenance is being performed. The idea is to gain a better idea
On Wed, 2006-05-10 at 17:10 -0500, Jim C. Nasby wrote:
On Thu, May 04, 2006 at 04:45:57PM +0200, Mario Splivalo wrote:
Well, here's the problem...
- Nested Loop (cost=0.00..176144.30 rows=57925 width=26)
(actual time=1074.984..992536.243 rows=57925 loops=1)
-
Something else worth considering is not using the normal
catalog methods
for storing information about temp tables, but hacking that together
would probably be a rather large task.
But the timings suggest, that it cannot be the catalogs in the worst
case
he showed.
0.101 ms BEGIN
1.451
16 matches
Mail list logo
