Обсуждение: waiting for harddisk
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
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
> 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.
On Mon, Mar 24, 2008 at 7:05 AM, petchimuthu lingam <spmlingam@gmail.com> 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.