From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Andre Schubert <andre(dot)schubert(at)km3(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: problem with pg_statistics |
Date: | 2003-06-27 08:43:01 |
Message-ID: | 4avnfvkjr8q7cl8ac6f01j8rddj4pjlte0@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 27 Jun 2003 08:07:35 +0200, Andre Schubert
<andre(dot)schubert(at)km3(dot)de> wrote:
>Traffic data are inserted every 5 minutes with the actual datetime
>of the transaction, thatswhy the table should be physically order by time_stamp.
So I'd expect a correlation of nearly 1. Why do your statistics show
a value of -0.479749? A negative correlation is a sign of descending
sort order, and correlation values closer to 0 indicate poor
correspondence between column values and tuple positions.
Could this be the effect of initial data loading? Are there any
updates or deletions in your traffic table?
>To answer Manfreds questions:
>> Andre, what hardware is this running on? What are the values of
>> shared_buffers, random_page_cost, effective_cache_size, ... ? Could
>> you show us the result of
>>
>> SELECT * FROM pg_stats
>> WHERE tablename = "tbl_traffic" AND attname = "time_stamp";
^ ^ ^ ^
Oops, these should have been single quotes. It's too hot here these
days :-)
>sort_mem = 32000
>shared_buffers = 13000
Personally I would set them to lower values, but if you have good
reasons ...
>#effective_cache_size = 1000 # default in 8k pages
This is definitely too low. With 512MB or more I tend to set this to
ca. 80% of available RAM. Use top and free to find hints for good
values.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Andre Schubert | 2003-06-27 09:10:58 | Re: problem with pg_statistics |
Previous Message | Andre Schubert | 2003-06-27 06:13:06 | Re: problem with pg_statistics |