Re: [PERFORM] problem with pg_statistics

2003-06-27 Thread Manfred Koizar
On Fri, 27 Jun 2003 11:10:58 +0200, Andre Schubert <[EMAIL PROTECTED]> wrote: >Once a month we delete the all data of the oldest month. >And after that a vacuum full verbose analyze is performed. >Could this cause reordering of the data ? I may be wrong, but I think VACUUM FULL starts taking tuple

Re: [PERFORM] problem with pg_statistics

2003-06-27 Thread Andre Schubert
On Fri, 27 Jun 2003 10:43:01 +0200 Manfred Koizar <[EMAIL PROTECTED]> wrote: > On Fri, 27 Jun 2003 08:07:35 +0200, Andre Schubert > <[EMAIL PROTECTED]> wrote: > >Traffic data are inserted every 5 minutes with the actual datetime > >of the transaction, thatswhy the table should be physically order

Re: [PERFORM] problem with pg_statistics

2003-06-27 Thread Manfred Koizar
On Fri, 27 Jun 2003 08:07:35 +0200, Andre Schubert <[EMAIL PROTECTED]> 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

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Andre Schubert
On Thu, 26 Jun 2003 12:03:52 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Manfred Koizar <[EMAIL PROTECTED]> writes: > > On Thu, 26 Jun 2003 10:08:05 -0400, Tom Lane <[EMAIL PROTECTED]> > > wrote: > >> Try reducing random_page_cost > > > With index scan cost being more than 25 * seq scan cost, I g

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Andre Schubert
On Thu, 26 Jun 2003 12:03:52 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Manfred Koizar <[EMAIL PROTECTED]> writes: > > On Thu, 26 Jun 2003 10:08:05 -0400, Tom Lane <[EMAIL PROTECTED]> > > wrote: > >> Try reducing random_page_cost > > > With index scan cost being more than 25 * seq scan cost, I g

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Tom Lane
Manfred Koizar <[EMAIL PROTECTED]> writes: > On Thu, 26 Jun 2003 10:08:05 -0400, Tom Lane <[EMAIL PROTECTED]> > wrote: >> Try reducing random_page_cost > With index scan cost being more than 25 * seq scan cost, I guess that > - all other things held equal - even random_page_cost = 1 wouldn't > hel

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Manfred Koizar
On Thu, 26 Jun 2003 10:08:05 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >Andre Schubert <[EMAIL PROTECTED]> writes: >> i think i need a little help with a problem with pg_statistic. > >Try reducing random_page_cost With index scan cost being more than 25 * seq scan cost, I guess that - all other t

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Tom Lane
Andre Schubert <[EMAIL PROTECTED]> writes: > i think i need a little help with a problem with pg_statistic. Try reducing random_page_cost --- although you'd be foolish to set it on the basis of just a single test query. Experiment with a few different tables, and keep in mind that repeated tests

[PERFORM] problem with pg_statistics

2003-06-26 Thread Andre Schubert
Hi, i think i need a little help with a problem with pg_statistic. Lets say i have a table to collect traffic-data. The table has a column time_stamp of type timesamptz. The table has a single-column index on time_stamp. The table has around 5 million records. If i delete all statistical data fro