[PERFORM] waiting for harddisk

2008-03-24 Thread petchimuthu lingam
i am using postgresql 8.1.8,

Following configurations:
   shared_buffers = 5000
work_mem = 65536
maintenance_work_mem = 65536
effective_cache_size = 16000
random_page_cost = 0.1

The cpu is waiting percentage goes upto 50%, and query result comes later,

i am using normal select query ( select * from table_name ).

table has more then 6 million records.



-- 
With Best Regards,
Petchimuthulingam S


Re: [PERFORM] waiting for harddisk

2008-03-24 Thread PFC

i am using postgresql 8.1.8,

Following configurations:
   shared_buffers = 5000
work_mem = 65536
maintenance_work_mem = 65536
effective_cache_size = 16000
random_page_cost = 0.1

The cpu is waiting percentage goes upto 50%, and query result comes  
later,


i am using normal select query ( select * from table_name ).

table has more then 6 million records.




	When you mean SELECT *, are you selecting the WHOLE 6 million records ?  
Without WHERE ? Or just a few rows ?

Please post EXPLAIN ANALYZE of your query.

-
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


Re: [PERFORM] waiting for harddisk

2008-03-24 Thread Scott Marlowe
On Mon, Mar 24, 2008 at 7:05 AM, petchimuthu lingam [EMAIL PROTECTED] wrote:
 i am using postgresql 8.1.8,

 Following configurations:
shared_buffers = 5000
 work_mem = 65536
 maintenance_work_mem = 65536
 effective_cache_size = 16000
  random_page_cost = 0.1

That number, 0.1 is not logical.  anything below 1.0 is generally a
bad idea, and means that you've got some other setting wrong.

 The cpu is waiting percentage goes upto 50%, and query result comes later,

 i am using normal select query ( select * from table_name ).

 table has more then 6 million records.

You need faster disks if you want sequential scans to go faster.  Look
into a decent RAID controller (Areca, Escalade (forgot what they're
called now) or LSI) with battery backed cache.  Run RAID-10 on it with
as many drives as you can afford to throw at the problem.

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance