Re: [PERFORM] [ADMIN] 2 server with same configuration but huge difference in performance

EX or ALTER TABLE statements that are being blocked, a transaction running on the table involved will cause those commands to be held until those transactions complete. If it's normal read/write queries to that are taking longer, ensure the database statistics are up to date by running an analyze. Keith

Re: [PERFORM] Partitioned tables in queries

in the query must be a constant, and cannot be a result of a built-in function in order for constraint_exclusion to work correctly? Thanks, Kevin Kevin Keith wrote: I have a case where I am partitioning tables based on a date range in version 8.1.4. For example: table_with_millions_of_

[PERFORM] Partitioned tables in queries

I have a case where I am partitioning tables based on a date range in version 8.1.4. For example: table_with_millions_of_records interaction_id char(16) primary key start_date timestamp (without timezone) - indexed .. other columns child_1 start_date >= 2006-07-21 00:00:00 child_2 start_

[PERFORM] view of view

view that filters, manipulates, and orders the data from the first view or a view that performs all the necessary calculations on the original tables? -- Kind Regards, Keith ---(end of broadcast)--- TIP 4: Have you searched our list archives

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

ing to go through the whole table eventually do you really need to sort the data at this point? -- Kind Regards, Keith ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PERFORM] Performance Tuning Article

archives for xeon sooner or later you will bump into something relevant. -- Kind Regards, Keith ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Performance Tuning Article

r data. Use RAID 1 (mirror) for your OS Use RAID 1 (mirror) for the WAL. Don't put anything else on the array holding the WAL. There have been problems with Xeon processors. -- Kind Regards, Keith ---(end of broadcast)--- TIP 3: if posting/re

Re: [PERFORM] Moving pg_xlog

On Wed, 01 Jun 2005 12:19:40 -0400, Tom Lane wrote > "Keith Worthington" <[EMAIL PROTECTED]> writes: > > I have been reading about increasing PostgreSQL performance > > by relocating the pg_xlog to a disk other than the one > > where the database resides. I

[PERFORM] Moving pg_xlog

create any installation issues the next time I upgrade PostgreSQL? TIA Kind Regards, Keith ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] COPY vs INSERT

that this is anywhere from 5-10x faster than INSERT statements on the whole, and sometimes 200x. Chris Unfortunately, COPY FROM '' can only be done by a superuser. If you that option then that is great. If not... -- Kind Regards, Keith ---(end of broadcast)

Re: [PERFORM] 4 way JOIN using aliases

On Tue, 12 Apr 2005 08:41:55 -0500, Dave Held wrote > > -Original Message- > > From: Keith Worthington [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 11, 2005 7:44 PM > > To: Neil Conway > > Cc: PostgreSQL Perform > > Subject: Re: [PERFORM] 4 way JOI

Re: [PERFORM] 4 way JOIN using aliases

Neil Conway wrote: Keith Worthington wrote: -> Seq Scan on tbl_current (cost=0.00..1775.57 rows=76457 width=31) (actual time=22.870..25.024 rows=605 loops=1) This rowcount is way off -- have you run ANALYZE recently? -Neil ---(end of broadc

Re: [PERFORM] Any way to speed this up?

ntnum, associatenum) > [snip] > > Joel Fradkin Joel, I am REALLY new at this and struggling to understand EXPLAIN ANALYZE output but for what it is worth it looks like the sort on a.locationid is taking up a lot of the time. I do not see an index on that column. I would suggest index

[PERFORM] 4 way JOIN using aliases

sc (cost=0.00..4.14 rows=214 width=32) (actual time=0.031..0.343 rows=214 loops=1) -> Hash (cost=1775.57..1775.57 rows=76457 width=31) (actual time=26.114..26.114 rows=0 loops=1) -> Seq Scan on tbl_current (cost=0.00..1775.57 rows=76457 width=31) (actual time=22.870..25.024 rows=605 loops=1) Total runtime: 158.053 ms Kind Regards, Keith ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[PERFORM] Triggers with FOR EACH STATEMENT

= rcrd_order.so_number; END LOOP; The data model table has an AFTER-UPDATE-STATEMENT trigger. CREATE TRIGGER tgr_update_allocated AFTER UPDATE ON tbl_detail FOR EACH STATEMENT EXECUTE PROCEDURE tf_update_allocated(); Kind Regards, Keith ---

[PERFORM] Dynamic query perormance

s are appreciated. Kind Regards, Keith CREATE OR REPLACE FUNCTION func_item_list("varchar") RETURNS SETOF VARCHAR AS $BODY$ DECLARE v_status ALIAS FOR $1; r_item_id RECORD; BEGIN --Build the record set using the appropriate query. IF lower(v_status) = 'activ

[PERFORM] View vs function

be faster? Or does the planner realize all this... SELECT * FROM view_big_query WHERE column1 = 1234; SELECT * FROM func_bug_query(1234); -- Kind Regards, Keith ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

[PERFORM] What's faster?

7.3.4     Keith