Re: problem with pg_statistics

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

In response to

Responses

Browse pgsql-performance by date

  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