[PERFORM] CPU 0.1% IOWAIT 99% for decisonnal queries

[Patrick Vedrines]

Hi everyone,   I'm developping a web decisonnal application based on -Red Hat 3 ES -Postgresql 8.0.1 -Dell poweredge 2850, Ram 2Gb, 2 procs, 3 Ghz, 1Mb cache and 4 disks ext3 10,000 r/mn I am alone in the box and there is not any crontab.   I have 2 databases (A and B) with exactly the same schemas: -one main table called "aggregate" having no indexes and supporting only SELECT statements (loaded one time a month with a new bundle of datas). Row size # 200 bytes (50 columns of type char(x) or integer)  -and several small 'reference' tables not shown by the following example for clarity reasons. -Database A : aggregate contains 2,300,000 records ( 500 Mb) -Database B : aggregate contains 9,000,000 records ( 2 Gb)   There is no index on the aggregate table since the criterias, their number and their scope are freely choosen by the customers.   The query :         select  sum(ca)          from aggregate            where  (issue_date >= '2004-01' and issue_date <= '2004-02' ); takes 5s on database A ( 5mn30s* the first time, probably to fill the cache) and  21mn* on database B (whatever it is the first time or not).   explain shows sequential scan of course:  Aggregate  (cost=655711.85..655711.85 rows=1 width=4)    ->  Seq Scan on "aggregate"  (cost=0.00..647411.70 rows=3320060 width=4)          Filter: ((issue_date >= '2004-01'::bpchar) AND (issue_date <= '2004-02'::bpchar))   *Here is the 'top' display for these response times: 91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle            total    0,0%    0,0%    0,2%   0,1%     0,0%   48,6%   51,0%            cpu00    0,0%    0,0%    0,0%   0,0%     0,0%    0,0%  100,0%            cpu01    0,0%    0,0%    1,0%   0,0%     0,0%   99,0%    0,0%            cpu02    0,0%    0,0%    0,0%   0,5%     0,0%    0,0%   99,5%            cpu03    0,0%    0,0%    0,0%   0,0%     0,0%   95,5%    4,5% Mem:  2061424k av, 2043944k used,   17480k free,       0k shrd,    6104k buff                    1551692k actv,  172496k in_d,   30452k in_c Swap: 2096440k av,       0k used, 2096440k free                 1792852k cached   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND 21983 postgres  20   0  9312 9312  8272 D     0,2  0,4   0:00   1 postmaster     1 root      15   0   488  488   432 S     0,0  0,0   0:06   2 init     2 root      RT   0     0    0     0 SW    0,0  0,0   0:00   0 migration/0 For the 5s response time, the 'top' command shows 0% iowait and 25% cpu.     - I guess this is a cache issue but how can I manage/control it ? Is Postgres managing it's own cache or does it use the OS cache ?   - Is using the cache is a good approach? It does not seem to work for large databases : I tryed several different values for postgres.conf and /proc/sys/kernel/shmmax without detecting any response time enhancement (For example : shared_buffers = 190000 , sort_mem = 4096 , effective_cache_size = 37000 and kernel/shmmax=1200000000 ) Do I have to upgrade the RAM to 6Gb or/and buy faster HD (of what type?) ? Moreover, a query on database B will destroy the cache previously build for database A, increasing the response time for the next query on database A. And I have in fact 15 databases !   - In my case, what should be the best parameters combination between postgres.conf and /proc/sys/kernel/shmmax ?   - is there a way to reduce the size of the "aggregate" table files (1Gb + 1Gb + 1 Gb + 0.8Gb = 3.8Gb for the "aggregate" table instead of 2Gb = 200 * 9,000,000 records) by playing with the data types or others parameters (fillfactor ?). Vacuum (even full) seems to be useless since the aggregate table supports only 'copy aggregate from' and 'select'.   - is it possible to define a sort of RAM filesystem (as it exists in DOS/Windows) which I could create and populate my databases into ? ...since the databases does not support updates for this application.   Sorry for my naive questions and my poor english but any help or advise will be greatly appreciated !   Patrick Vedrines   PS (maybe of interest for some users like me) : I created a partition on a new similar disk but on the last cylinders (near the periphery) and copied the database B into it: the response time is 25% faster (i.e. 15mn instead of 21mn). But 15 mn is still too long for my customers (5 mn would be nice).