Re: [PERFORM] Worsening performance with 7.4 on flash-based system

On 4/29/06, Greg Stumph <[EMAIL PROTECTED]> wrote: Well, since I got no response at all to this message, I can only assume that I've asked the question in an insufficient way, or else that no one has anything to offer on our problem. This was my first post to the list, so if there's a better way

Re: [PERFORM] Easy question

You have a functional index on UPPER(municipo), right?  How large is the table?On 26 Apr 2006 18:26:07 -0700, Bert < [EMAIL PROTECTED]> wrote:Thanks,But the performance is the same just the formating is more simple. Greets,Bert---(end of broadcast)---

Re: [PERFORM] Worsening performance with 7.4 on flash-based system

Usually when simple queries take a long time to run, it's the system tables (pg_*) that have become bloated and need vacuuming. But that's just random guess on my part w/o my detailed info. Greg Stumph wrote: Well, since I got no response at all to this message, I can only assume that I've as

Re: [PERFORM] Slow restoration question

Tom Lane <[EMAIL PROTECTED]> schrieb: > Eric Lam <[EMAIL PROTECTED]> writes: > > what is the quickest way of dumping a DB and restoring it? I have done a > > >"pg_dump -D database | split --line-bytes 1546m part" > > Don't use "-D" if you want fast restore ... hehe, yes ;-) http://people.p

Re: [PERFORM] Slow restoration question

Eric Lam <[EMAIL PROTECTED]> writes: > what is the quickest way of dumping a DB and restoring it? I have done a >"pg_dump -D database | split --line-bytes 1546m part" Don't use "-D" if you want fast restore ... regards, tom lane ---(end of bro

Re: [PERFORM] Worsening performance with 7.4 on flash-based system

Well, since I got no response at all to this message, I can only assume that I've asked the question in an insufficient way, or else that no one has anything to offer on our problem. This was my first post to the list, so if there's a better way I should be asking this, or different data I shou

[PERFORM] Performance Issues on Opteron Dual Core

Hello, We are currently developing a web application and have the webserver and PostgreSQL with our dev db running on a machine with these specs: Win 2003 standard AMD Athlon XP 3000 / 2.1 GHZ 2 Gig ram 120 gig SATA HD PostgreSQL 8.1.0 Default pgsql configuration + shared buffers = 30,000 The p

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

I'd be interested in those numbers once you get them, especially for ext3. We just picked up an HP MSA1500cs with the MSA50 sled, and I am curious as to how best to configure it for Postgres. My server is the HP DL585 (quad, dual-core Opteron, 16GB RAM) with 4 HD bays run by a HP SmartArray 5i co

Re: [PERFORM] Easy question

Thanks, But the performance is the same just the formating is more simple. Greets, Bert ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

[PERFORM] Slow restoration question

Hello list, what is the quickest way of dumping a DB and restoring it? I have done a "pg_dump -D database | split --line-bytes 1546m part" Restoration as "cat part* | psql database 2> errors 1>/dev/null" all dumpfiles total about 17Gb. It has been running for 50ish hrs and up to about the

Re: [PERFORM] Easy question

SELECT geom, group, production_facs FROM south_america WHERE UPPER(municipio) IN ('ACRE', 'ADJUNTAS', 'AGUADA'); <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi List > I have maybe an easy question but i do not find an answer, i have this > SQL query: > > SELECT geom,group,prod

Re: [PERFORM] Why so slow?

On Sat, Apr 29, 2006 at 11:18:10AM +0800, K C Lau wrote: I apologize for simplistic ideas again. I presume that the equivalent tuple header information is not maintained for index entries. What if they are, probably only for the most commonly used index types to allow recycling where possible?