Re: [PERFORM] gist indexes for distance calculations

> > Thanks a lot for all the help, if you can lead me to any docs/articles, > I'll gladly read them. I found this: http://en.wikipedia.org/wiki/R-tree Looks like what Tom was talking about, ja? Karim

Re: [PERFORM] Performance problems testing with Spamassassin

I am only guessing at this point. If you need to support a massive initial data load, further time savings are to be had by doing COPY instead of 126,000 inserts. Please do keep us updated. Thanking all the gods and/or developers for spamassassin, -- Karim Nassa

Re: [PERFORM] Performance problems testing with Spamassassin

someone smarter could optimize further. Anyone with a super-spifty machine wanna see if there is an improvement here? -- Karim Nassar <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Two queries are better than one?

de, for their respective tables. batch/id is unique, so there is only one record from order, and only one client to associate. Clearer? -- Karim Nassar <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please s

Re: [PERFORM] Two queries are better than one?

On Thu, 2005-07-28 at 21:01 -0500, John A Meinel wrote: > > Also, did you run it *lots* of times to make sure that this isn't just > noise? If a dozen is lots, yes. :-) It was very consistent as I repeatedly ran it. -- Karim Nassar <[EMAIL PROTECTED]> --

[PERFORM] Two queries are better than one?

g order_pkey on order (cost=0.00..6.02 rows=1 width=486) (actual time=0.064..0.066 rows=1 loops=1) Index Cond: ((ord_batch = '343B'::bpchar) AND (ord_id = '12-645'::bpchar)) -> Index Scan using client_pkey on client (cost=0.00..5.98 rows=1 width=51) (actual tim

Re: [PERFORM] Performance problems testing with Spamassassin 3.1.0

On Wed, 2005-07-27 at 14:35 -0800, Matthew Schumacher wrote: > I put the rest of the schema up at > http://www.aptalaska.net/~matt.s/bayes/bayes_pg.sql in case someone > needs to see it too. Do you have sample data too? -- Karim Nassar Collaborative Computing Lab of NAU Office: (928)

[PERFORM] What's a lot of connections?

that many. -- Karim Nassar <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] Performance Tuning Article

Design and Layout", after new table layout: "Take for example the employee table above. Your probably only display active employees throughout the majority of the application..." Do you mean "You're probably only displaying"? HTH, -- Karim Nassar <[EMAIL PROTEC

Re: [PERFORM] Index ot being used

many architectures and configurations for you to accurately optimize inside your program, and this gives you and your users an easy out. if ($do_db_optimization == 1) { $DB->do("SET ENABLE_SEQSCAN TO OFF") || die... } else { # do nothing -- postgresql will figure it out } -- Karim

[PERFORM] VACUUM on duplicate DB gives FSM and total pages discrepancies

e_work_mem 262144 16384 shared_buffers 3 1000 Thanks, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, Flagstaff, Arizona 86011 Office: (928) 523-5868 -=- Mobile: (928

Re: [PERFORM] Delete query takes exorbitant amount of time

re equivalent: both create integer columns" TIA, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, Flagstaff, Arizona 86011 Office: (928) 523-5868 -=- Mobile: (928) 699-9221

Re: [PERFORM] Delete query takes exorbitant amount of time

olution for this scenario. I guess I was wondering if there is other general tuning advice for such large table indexes such as increasing statistics, etc. Thanks, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, F

Re: [PERFORM] [BUGS] BUG #1552: massive performance hit between 7.4

te.html > It doesn't go into great lengths about all the reasons why those > recommendations are good ones - but they are clear. Simon, this begs the question: what changed from 7.4->8.0 to require he modify his script? TIA, -- Karim Nassar Department of Computer Science Box 1

Re: [PERFORM] Delete query takes exorbitant amount of time

On Sat, 2005-03-26 at 15:18 -0800, Stephan Szabo wrote: > On Sat, 26 Mar 2005, Karim Nassar wrote: > > > On Sat, 2005-03-26 at 07:55 -0800, Stephan Szabo wrote: > > > That seems like it should be okay, hmm, what does something like: > > > > > > PREPARE test(

Re: [PERFORM] Delete query takes exorbitant amount of time

actual time=11608.402..11608.402 rows=0 loops=1) Filter: (id_int_sensor_meas_type = $1) Total runtime: 11608.441 ms (3 rows) -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, Flagstaff, Arizo

Re: [PERFORM] Delete query takes exorbitant amount of time

reated timestamp with time zone NOT NULL DEFAULT now(), created_by TEXT NOT NULL REFERENCES public.person(id_person)); CREATE INDEX measurement__id_int_sensor_meas_type_idx ON measurement(id_int_sensor_meas_type); Regards, -- Karim Nassar Department of Computer Science Box 15600, Coll

Re: [PERFORM] Delete query takes exorbitant amount of time

On Thu, 2005-03-24 at 19:52 -0500, Tom Lane wrote: > Karim Nassar <[EMAIL PROTECTED]> writes: > > Here is the statement: > > > orfs=# explain analyze DELETE FROM int_sensor_meas_type WHERE > > id_meas_type I

[PERFORM] Delete query takes exorbitant amount of time

loops=1) Total runtime: 1.340 ms (7 rows) I have posted my tables, data and test cases here: http://ccl.cens.nau.edu/~kan4/testing/long-delete Where do I go from here? Thanks in advance, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Nor

Re: [PERFORM] Hardware questions

ent threads on this topic: http://archives.postgresql.org/pgsql-performance/2005-03/msg00177.php http://archives.postgresql.org/pgsql-performance/2005-03/msg00238.php http://archives.postgresql.org/pgsql-performance/2005-03/msg00406.php HTH, -- Karim Nassar Department of Computer Science Box 15

Re: [PERFORM] What's better: Raid 0 or disk for seperate pg_xlog

spindles as such: - first disk: RAID1 to disk 1 - next 2 disks: RAID 0 across the above Do I grok it? Thanks again, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, Flagstaff, Arizona 86011 Office: (9

[PERFORM] What's better: Raid 0 or disk for seperate pg_xlog

linux). What's "theoretically better"? 1) OS and pg_xlog on one disk, rest of postgresql on the other? (if I understand the above correctly) 2) Everything striped Raid 0? 3) TIA, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Nat

Re: [PERFORM] 64bit Opteron multi drive raid. Help with best config

Then this: http://www.powerpostgresql.com/Downloads/annotated_conf_80.html http://www.powerpostgresql.com/Downloads/annotated_conf_80.pdf Someone else might have an example config for you. HTH, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences