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] Similar querys, better execution time on worst execution plan

2003-06-26 Thread SZUCS Gábor
*happy* :))) G. --- cut here --- - Original Message - From: "Fernando Papa" <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 3:33 PM I need to recheck about the "quality" of "active" field. Really I don't know if I found a lot of

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

Re: [PERFORM] Similar querys, better execution time on worst execution plan

2003-06-26 Thread Fernando Papa
> -Mensaje original- > De: SZUCS Gábor [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 26 de junio de 2003 7:31 > Para: [EMAIL PROTECTED] > Asunto: Re: [PERFORM] Similar querys, better execution time > on worst execution plan > > > Fernando, > > 1. Try EXPLAIN ANALYZE. Cost alone isn'

[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

Re: [PERFORM] Performance advice

2003-06-26 Thread Manfred Koizar
On Wed, 25 Jun 2003 11:47:48 +0200, "Michael Mattox" <[EMAIL PROTECTED]> wrote: >> |INFO: --Relation public.jdo_sequencex-- >> |INFO: Pages 28: Changed 1, Empty 0; Tup 1: Vac 5124, Keep 0, UnUsed 0. >> ^ >> This table could stand more frequent V

Re: [PERFORM] Similar querys, better execution time on worst execution plan

2003-06-26 Thread SZUCS Gábor
Fernando, 1. Try EXPLAIN ANALYZE. Cost alone isn't an absolute measure. I think it's only to see which parts of the query are expected to be slowest. However, EXP ANA will give you exact times in msec (which effectively means it executes the query). 2. I think calling upper() for each row costs m