Re: [PERFORM] Has anyone run on the new G5 yet
Paul Tuckfield wrote: > Biggest problem I've had in the past w. linux in general is that it > seems to make poor VM choices under heavy filesystem IO. I don't really > get exactly where it's going wrong , but I've had numerous experiences > on older systems where bursty IO would seem to cause paging on the box > (pageout of pieces of the oracle SGA shared memory) which is a > performance disaseter. It seems to happen even when the shared memory > was sized reasonably below the size of physical ram, presumably because > linux is too aggressive in allocating filesystem cache (?) anyway, it > seems to make decisions based on desire for zippy workstation > performance and gets burned on thruput on database servers. I'm > guessing this may be an issue for you , when doing heavy IO. Thing is, > it'll show like you're IO bound kindof because you're thrashing. This is not surprising. There has always been an issue with dynamic buffer cache systems contending with memory used by processes. It takes a long time to get the balance right, and still there might be cases where it gets things wrong. Isn't there a Linux option to lock shared memory in to RAM? If so, we should document this in our manuals, but right now, there is no mention of it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PERFORM] Pgbench results
Greetings all, I'm wondering is there a website where people can submit their pgbench results along with their hardware and configuration's? If so where are they at? I have yet to find any. I think this could be a very useful tool not only for people looking at setting up a new server but for people trying to tune their db... Thanks Rob ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] query using cpu nearly 100%, why?
On Friday 05 December 2003 21:03, LIANHE SHAO wrote: > Hello, > I use php as front-end to query our database. When I use System Monitor to > check the usage of cpu and memory, I noticed that the cpu very easily gets > up to 100%. Is that normal? if not, could someone points out possible > reason? The idea is that CPU should go to 100% when there's work to be done, and drop off when the system is idle. There's nothing to be gained with having the CPU at 50% and taking twice as long to perform a task. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] query using cpu nearly 100%, why?
LIANHE SHAO <[EMAIL PROTECTED]> writes: > Hello, I use php as front-end to query our database. When I use > System Monitor to check the usage of cpu and memory, I noticed that > the cpu very easily gets up to 100%. Is that normal? if not, could > someone points out possible reason? You haven't given us nearly enough information about the problem to allow us to provide any meaningful advice. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Slow UPADTE, compared to INSERT
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > This is not a bug. It is just that people find it confusing when > postgresql planner consider seemingly same type as different. It certainly is a bug, or at least a deficiency: PostgreSQL planner *could* use the index to process the query, but the planner doesn't consider doing so. The fact that it isn't able to do the necessary type coercion is the *cause* of the bug, not a defence for this behavior. > AFAIK, the fix in CVS is to make indexes operatable with seemingly > compatible types. Which does not change the fact that postgresql can > not upgrade data types on it's own. I'm not sure what you mean by that. In any case, I just checked, and it does seem Tom has fixed this in CVS: template1=# create table abc (b int8); CREATE TABLE template1=# set enable_seqscan = false; SET template1=# create index abc_b_idx on abc (b); CREATE INDEX template1=# explain select * from abc where b = 4; QUERY PLAN -- Index Scan using abc_b_idx on abc (cost=0.00..17.07 rows=5 width=8) Index Cond: (b = 4) (2 rows) Cool! -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
