[PERFORM] Query plan - now what?

Well, now that I have the plan for my slow-running query, what do I do? Where should I focus my attention? Thanks. -David Hash Join (cost=16620.59..22331.88 rows=40133 width=266) (actual time=118773.28..580889.01 rows=57076 loops=1) - Hash Join (cost=16619.49..21628.48 rows=40133

Re: [PERFORM] Query plan - now what?

David Shadovitz [EMAIL PROTECTED] writes: Well, now that I have the plan for my slow-running query, what do I do? This is not very informative when you didn't show us the query nor the table schemas (column datatypes and the existence of indexes are the important parts). I have a feeling that

Re: [PERFORM] Query plan - now what?

This is not very informative when you didn't show us the query nor the table schemas.. BTW, what did you do with this, print and OCR it? Tom, I work in a classified environment, so I had to sanitize the query plan, print it, and OCR it. I spent a lot of time fixing typos, but I guess at

Re: [PERFORM] Query plan - now what?

David Shadovitz [EMAIL PROTECTED] writes: If you think that you or anyone else would invest the time, I could post more info. I doubt you will get any useful help if you don't post more info. I will also try Shridhar's suggestions on statistics_target and enable_hash_join. It seemed to me

[PERFORM] Performance related to size of tables

Hi everyone, I found that performance get worse as the size of a given table increases. I mean, for example I´ve just run some scripts shown in http://www.potentialtech.com/wmoran/postgresql.php I understand that those scripts are designed to see the behavior of postgresql under different

[PERFORM] Update on putting WAL on ramdisk/

Some arbitrary data processing job WAL on single drive: 7.990 rec/s WAL on 2nd IDE drive: 8.329 rec/s WAL on tmpfs: 13.172 rec/s A huge jump in performance but a bit scary having a WAL that can disappear at any time. I'm gonna workup a rsync script and do some power-off experiments to see how

Re: [PERFORM] Update on putting WAL on ramdisk/

WAL on single drive: 7.990 rec/s WAL on 2nd IDE drive: 8.329 rec/s WAL on tmpfs: 13.172 rec/s A huge jump in performance but a bit scary having a WAL that can disappear at any time. I'm gonna workup a rsync script and do some power-off experiments to see how badly it gets mangled. Surely

Re: [PERFORM] Update on putting WAL on ramdisk/

Russell Garrett wrote: WAL on single drive: 7.990 rec/s WAL on 2nd IDE drive: 8.329 rec/s WAL on tmpfs: 13.172 rec/s A huge jump in performance but a bit scary having a WAL that can disappear at any time. I'm gonna workup a rsync script and do some power-off experiments to see how badly it gets

Re: [PERFORM] [HACKERS] fsync method checking

Manfred Spraul [EMAIL PROTECTED] writes: One advantage of a seperate write and fsync call is better performance for the writes that are triggered within AdvanceXLInsertBuffer: I'm not sure how often that's necessary, but it's a write while holding both the WALWriteLock and WALInsertLock. If

Re: [PERFORM] [ADMIN] ODBC Driver generates a too big windows swap file and

On Fri, 12 Dec 2003, Rhaoni Chiu Pereira wrote: Hi, is there a switch in your pgsql/odbc connector to enable cursors? If so, try turning that on. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ?