Re: Are bitmap index scans slow to start? - Mailing list pgsql-performance

From Carlo Stonebanks
Subject Re: Are bitmap index scans slow to start?
Date
Msg-id 010601ce137a$266b7f00$73427d00$@sympatico.ca
Whole thread Raw
In response to Re: Are bitmap index scans slow to start?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Are bitmap index scans slow to start?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance

Hi Jeff, thanks for the insight.

 

<< And then the next question would be, once they are in the cache, why don't they stay there?  For that you would have to know what other types of activities are going on that might be driving the data out of the cache.

>> 

 

To give you an idea of the activity level, each physical machine hosts multiple DB’s with the same structure – one DB per client.

 

We run automated ETL processes which digests client feeds (E) normalizes them (T) and then stores them in our DB (L).

 

Looking at the stats from our audit log, the average feed load is 4 hours, divided up into 14 client sessions. Each session averages about 50 write (update, insert, no deletes) operations per second, representing 700 write operations per second. The ratio of reads per write is pretty high as the system goes through the transformation process.

 

Since I don’t know how this compares to other PG installations, the question of using periodic REINDEX and CLUSTER brings up these questions:

 

1)      Because we are hosting multiple DB’s, what is the impact on OS and disk caches?

2)      Is there an automated CLUSTER and REINDEX strategy that will not interfere with normal operations?

3)      By PG standards, is this a busy DB - and does explain why the general caches expire?

 

Thanks,

 

Carlo

pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Server stalls, all CPU 100% system time
Next
From: Maciek Sakrejda
Date:
Subject: Re: Avoiding Recheck Cond when using Select Distinct