Re: [PERFORM] Suspending SELECTs

2006-01-18 Thread Harry Jackson
Your experiment made far too many assumptions and the data does not stand up to scrutiny. On 1/18/06, Alessandro Baretta <[EMAIL PROTECTED]> wrote: > Results: I'll omit the numerical data, which everyone can easily obtain in > only > a few minutes, repeating the experiment. I used several query s

Re: [PERFORM] help tuning queries on large database

2006-01-09 Thread Harry Jackson
On 1/9/06, Kelly Burkhart <[EMAIL PROTECTED]> wrote: > On 1/8/06, Ron <[EMAIL PROTECTED]> wrote: > > > > Among the other tricks having lots of RAM allows: > > If some of your tables are Read Only or VERY rarely written to, you > > can preload them at boot time and make them RAM resident using the

Re: [PERFORM] help tuning queries on large database

2006-01-06 Thread Harry Jackson
On 1/6/06, peter royal <[EMAIL PROTECTED]> wrote: > PostgreSQL 8.1.1 > > shared_buffers = 1 # (It was higher, 50k, but didn't help any, > so brought down to free ram for disk cache) > work_mem = 8196 > random_page_cost = 3 > effective_cache_size = 25 I have played with both disk cache set

Re: [PERFORM] CPU and RAM

2005-12-30 Thread Harry Jackson
On 24 Dec 2005 10:25:09 -0500, Greg Stark <[EMAIL PROTECTED]> wrote: > > Harry Jackson <[EMAIL PROTECTED]> writes: > > > I always look at the explain plans. > > > > =# explain select item_id, term_frequency from

[PERFORM] CPU and RAM

2005-12-21 Thread Harry Jackson
I am currently using a dual Opteron (248) single core system (RAM PC3200) and for a change I am finding that the bottleneck is not disk I/O but CPU/RAM (not sure which). The reason for this is that the most frequently accessed tables/indexes are all held in RAM and when querying the database there

Re: [PERFORM] PostgreSQL performance question.

2005-12-17 Thread Harry Jackson
On 12/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > PostgreSQL 8.1.1 should give you greater performance... Indeed it has. I am seeing a 25% increase in one particular select statement. This increases to 32% with set enable_bitmapscan to off; I also ran a test script full of commo

Re: [PERFORM] Crashing DB or Server?

2005-12-16 Thread Harry Jackson
On 12/16/05, Moritz Bayer <[EMAIL PROTECTED]> wrote: > This is really weird, just a few hours ago the machine run very smooth > serving the data for a big portal. Can you log the statements that are taking a long time and post them to the list with the table structures and indexes for the tables

[PERFORM] PostgreSQL performance question.

2005-12-14 Thread Harry Jackson
my config file. max_fsm_pages = 50 # I am thinking this might be a bit low. max_fsm_relations = 1000 Any pointers to better hardware or recommendations on settings gladly recieved. Regards, Harry Jackson. -- http://www.hjackson.orghttp://www.uklug.co.uk