[PERFORM] Performance with 2 AMD/Opteron 2.6Ghz and 8gig DDR PC3200

-- Forwarded message --From: Kjell Tore Fossbakk <[EMAIL PROTECTED]>Date: Jul 26, 2006 8:55 AM Subject: Performance with 2 AMD/Opteron 2.6Ghz and 8gig DDR PC3200To: [EMAIL PROTECTED]Hello!I have upgraded my server to an HP Proliant DL585. It got two Processor motherboards, each hold

Re: [PERFORM] Disk writes

> I could I discover who is sending so many data to the disks? Documentation/laptop-mode.txt in the Linux kernel tree has some instructions how to track down unwanted disk writes. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Alle

Re: [PERFORM] Savepoint performance

My understanding of EDB's approach is that our prototype just implicitly does a savepoint before each INSERT, UPDATE, or DELETE statement inside of PLpgSQL. We then rollback to that savepoint if a sql error occurs. I don 't believe our prelim approach changes any transaction start/end semantics

Re: [PERFORM] Savepoint performance

"Denis Lussier" <[EMAIL PROTECTED]> writes: > Would the community be potentially interested in this feature if we created > a BSD Postgres patch of this feature for PLpgSQL (likely for 8.3)?? Based on our rather disastrous experiment in 7.3, I'd say that fooling around with transaction start/end s

[PERFORM] Disk writes

Hi,   We've a fedora core 3 box with PostgreSQL 8.0.   There is some performance problems with the server and I discovered with vmstat tool that there is some process writing a lot of information in the disk subsystem.   I stopped the database and even so vmstat showed the same rates of disk write

Re: [PERFORM] Savepoint performance

We've actually done some prelim benchmarking of this feature about six months ago and we are actively considering adding it to our "closer to Oracle" version of PLpgSQL.   I certainly don't want to suggest that it's a good idea to do this because it's Oracle compatible.  :-)   I'll get someone to

Re: [PERFORM] Savepoint performance

On 7/27/06, Mark Lewis <[EMAIL PROTECTED]> wrote: All, I support a system that runs on several databases including PostgreSQL. I've noticed that the other DB's always put an implicit savepoint before each statement executed, and roll back to that savepoint if the statement fails for some reason.

Re: [PERFORM] Query plan issue when upgrading to postgres 8.14 (from

Ioana Danes <[EMAIL PROTECTED]> writes: > Does anyone now what the problem is with the following select when > upgrading to postgresql 8.1.4 the query plan does not use the indexes as in > postgresql 8.0.3. The planner doesn't have enough information about the correlation between testtype

Re: [PERFORM] performance issue with a specific query

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Joshua D. Drake wrote: >> Enterprises are not going to compile. They are going to accept the >> latest support by vendor release. >> >> Redhat has a tendency to be incredibly stupid about this particular >> area of their packaging. > Stupid how? Re

Re: [PERFORM] Savepoint performance

Mark Lewis wrote: > So my question is, how expensive is setting a savepoint in PG? If it's > not too expensive, I'm wondering if it would be feasible to add a config > parameter to psql or other client interfaces (thinking specifically of > jdbc here) to do it automatically. Doing so would make

Re: [PERFORM] Query plan issue when upgrading to postgres 8.14 (from

Hi everyone,I posted this question some time ago and I did not get any answer so here I am again. Does anyone now what the problem is with the following select when upgrading to postgresql 8.1.4 the query plan does not use the indexes as in postgresql 8.0.3. Here are the results of my que

[PERFORM] Savepoint performance

All, I support a system that runs on several databases including PostgreSQL. I've noticed that the other DB's always put an implicit savepoint before each statement executed, and roll back to that savepoint if the statement fails for some reason. PG does not, so unless you manually specify a save

Re: [PERFORM] performance issue with a specific query

Joshua D. Drake wrote: > >> > > > >try turning off genetic query optimization. regarding the rhel4 > >issue...does rhel not come with a c compiler? :) > > Enterprises are not going to compile. They are going to accept the > latest support by vendor release. > > Redhat has a tendency to be incr

Re: [PERFORM] performance issue with a specific query

try turning off genetic query optimization. regarding the rhel4 issue...does rhel not come with a c compiler? :) Enterprises are not going to compile. They are going to accept the latest support by vendor release. Redhat has a tendency to be incredibly stupid about this particular area

Re: [PERFORM] performance issue with a specific query

On 7/27/06, Eliott <[EMAIL PROTECTED]> wrote: Hi! I hope I'm sending my question to the right list, please don't flame if it's the wrong one. I have noticed that while a query runs in about 1.5seconds on a 8.xx version postgresql server on our 7.4.13 it takes around 15-20 minutes. Since we are

Re: [PERFORM] performance issue with a specific query

On Thu, 2006-07-27 at 09:23, Eliott wrote: > Hi! > > I hope I'm sending my question to the right list, please don't flame > if it's the wrong one. > > I have noticed that while a query runs in about 1.5seconds on a 8.xx > version postgresql server on our 7.4.13 it takes around 15-20 minutes. > Si

[PERFORM] performance issue with a specific query

Hi!I hope I'm sending my question to the right list, please don't flame if it's the wrong one.I have noticed that while a query runs in about 1.5seconds on a 8.xx version postgresql server on our 7.4.13 it takes around 15-20 minutes. Since we are using RHEL4 on our server we are stuck with 7.4.13.