[PERFORM] very high CPU usage in "top", but not in "mpstat"

Hello all,   We are using Postgres 7.3 with JBoss 3.2.3 on a Linux Fedora 1.0 box.   When I am looking at CPU activity with “top”, I often see something like:     PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND 14154 postgres  25   0  3592 3592  2924    R 

Re: [PERFORM] Horribly slow hash join

Tom Lane <[EMAIL PROTECTED]> writes: > Modding by a *non* power of 2 (esp. a prime) mixes the bits quite well, > and is likely faster than any multiple-instruction way to do the same. > > The quoted article seems to be by someone who has spent a lot of time > counting assembly cycles and none at

[PERFORM] Adapting Oracle S.A.M.E. Methodology for Postgres

I mentioned this at the tail end of a long post in another thread, but I have been researching how to configure Postgres for a RAID 10 SAME configuration as described in the Oracle paper "Optimal Storage Configuration Made Easy" (http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf). H

Re: [PERFORM] Recommended File System Configuration

Chris Browne wrote: The results have not been totally conclusive... - Several have found JFS to be a bit faster than anything else on Linux, but some data loss problems have been experienced; - ext2 has the significant demerit that with big filesystems, fsck will "take forever" to run; - e

[PERFORM] pg_stat

Hi, I have query: select pg_stat_get_numscans(76529669), pg_stat_get_blocks_fetched(76529669), pg_stat_get_blocks_hit(76529669); The result is: pg_stat_get_numscans | pg_stat_get_blocks_fetched | pg_stat_get_blocks_hit --++

Re: [PERFORM] cache table

Joseph Shraibman <[EMAIL PROTECTED]> writes: > scott.marlowe wrote: > > > I think you might be interested in materialized views. You could create this > > as a materialized view which should be very fast to just select * from. > > That seems to be the count table I envisioned. It just hides th

Re: [PERFORM] Bug in optimizer

On Mon, May 03, 2004 at 18:08:23 +0200, Timo Nentwig <[EMAIL PROTECTED]> wrote: > > This is very slow: This kind of question should be asked on the performance list. > > SELECT urls.id FROM urls WHERE > ( > urls.id <> ALL (SELECT html.urlid FROM html) > ); > > ...while this is quite fa

Re: [PERFORM] cache table

scott.marlowe wrote: I think you might be interested in materialized views. You could create this as a materialized view which should be very fast to just select * from. That seems to be the count table I envisioned. It just hides the details for me. It still has the problems of an extra UPDA

Re: [PERFORM] cache table

On Mon, 3 May 2004, Joseph Shraibman wrote: > I have a big table with some int fields. I frequently need to do > queries like: > > SELECT if2, count(*) FROM table WHERE if1 = 20 GROUP BY if2; > > The problem is that this is slow and frequently requires a seqscan. I'd > like to cache the resul

Re: [PERFORM] linux distro for better pg performance

The comparison is actually dead on. If you have lots of write through / read behind cache, RAID 5 can run very quickly, until the write rate overwhelms the cache - at which point the 4 I/O per write / 2 per read stops it. This means that RAID 5 works, except when stressed, which is a bad paradigm.

Re: [PERFORM] Fwd: FreeBSD, PostgreSQL, semwait and sbwait!

I am wondering if your wait is caused by contention between pg_autovacuum and the DELETE that is running. Your large Pg blocksize (32K) *may* be contributing to any possible contention as well. Maybe try disabling pg_autovacuum to see if there is any change in behaviour. Also going through my h