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
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 results in
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
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
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;
-
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).
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 all
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 99.1 0.3
93:53 0
Joseph Shraibman [EMAIL PROTECTED] writes:
J. Andrew Rogers wrote:
Do these features make a difference? Far more than you would imagine. On one
postgres server I just upgraded, we went from a 3Ware 8x7200-RPM
RAID-10 configuration to an LSI 320-2 SCSI 3x10k RAID-5, with 256M
Is raid
