Re: [PERFORM] Huge performance problem between 7.4.1 and 8.0.3 -

n it with -d2 or so and make sure that it is actually doing the vacuuming needed. -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] performance problems ... 100 cpu utilization

wrote: David Mitchell wrote: What is the load average on this machine? Do you do many updates? If you do a lot of updates, perhaps you haven't vacuumed recently. We were seeing similar symptoms when we started load testing our stuff and it turned out we were vacuuming too infrequently.

Re: [PERFORM] performance problems ... 100 cpu utilization

--(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 1: if posti

Re: [PERFORM] plain inserts and deletes very slow

machine or what? Regards David Enrico Weigelt wrote: * David Mitchell <[EMAIL PROTECTED]> wrote: Perhaps if you are doing a lot of inserts and deletes, vacuuming every 6 minutes would be closer to your mark. Try vacuuming every 15 minutes for a start and see how that affects things (

Re: [PERFORM] plain inserts and deletes very slow

). David Enrico Weigelt wrote: * David Mitchell <[EMAIL PROTECTED]> wrote: Did you vacuum full? When you do lots of inserts and deletes, dead tuples get left behind. When you vacuum, postgres will reuse those dead tuples, but if you don't vacuum for a long time these tuples will bu

Re: [PERFORM] plain inserts and deletes very slow

to mention: + linux-2.6.9 + postgres-7.4.6 + intel celeron 2ghz + intel ultra ata controller + 768mb ram cu -- David Mitchell Software Engineer Telogis NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual

Re: [PERFORM] How can I speed up this function?

NOT NULL, data text NOT NULL, CONSTRAINT pending_statement_pkey PRIMARY KEY (id) ) WITHOUT OIDS; CREATE UNIQUE INDEX idx_stmt_tran_id_id ON dbmirror.pending_statement USING btree (transaction_id, id); Postgres 8.0.1 on Linux. Any Help would be greatly appreciated. Regards -- David Mitchell Software Engineer

Re: [PERFORM] How can I speed up this function?

UNIQUE INDEX idx_stmt_tran_id_id ON dbmirror.pending_statement USING btree (transaction_id, id); Postgres 8.0.1 on Linux. Any Help would be greatly appreciated. Regards -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 8: explain analy

Re: [PERFORM] How can I speed up this function?

t the data at this point? -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] How can I speed up this function?

worker process that takes care of actually committing to the database. Cheers -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] How can I speed up this function?

Christopher Kings-Lynne wrote: What's wrong with Slony? Because it's not multi-master. Our mirroring package is. -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go

[PERFORM] How can I speed up this function?

UNIQUE INDEX idx_stmt_tran_id_id ON dbmirror.pending_statement USING btree (transaction_id, id); Postgres 8.0.1 on Linux. Any Help would be greatly appreciated. Regards -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 8: explain analyze is your friend