Re: Index usage and wrong cost analisys - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Index usage and wrong cost analisys
Date
Msg-id 20030826130416.GC5282@svana.org
Whole thread Raw
In response to Re: Index usage and wrong cost analisys  (Pedro Alves <pmalves@think.pt>)
List pgsql-general
Look through the docs. By altering the values of random_page_cost,
effect_cache_size and cpu_tuple_cost you can make the estimates approximate
real life better.

On Tue, Aug 26, 2003 at 12:32:23PM +0100, Pedro Alves wrote:
>
>
>
>     One more thing I just noticed. Right after making a vacuum analyze on
> the table, I saw the following:
>
>     Seq scan:
>
>         - Cost: 10484
>         - Timing: 624ms
>
>     Index scan (with enable_seqscan = false):
>
>         - Cost: 10628
>         - Timing: 41ms
>
>
>     In production state the query goes up to a minute long (I ran this in a
> test database) and it takes less than a second using indexes. What can be
> causing this?
>
>
>     Is it safe to turn enable_seqscan = false in production environment?
>
>
>
>     Thanks
>
>
>
> On Tue, Aug 26, 2003 at 09:59:35AM +0100, Pedro Alves wrote:
> >
> > First of all tkx for the answer, Dennis.
> >
> > The vacuum analyze is run on daily basis, so that cannot be the point.
> >
> > Is there any way to force the planner to use the index?
> >
> >
> > Bellow is the explain analyze of the querys. Indeed, the second range has
> > more rows (9105 / 21503), but is this SO big that the planner cannot
> > handle?
> >
> >
> > This is running in a dedicated machine with 512Mb ram. Is there any
> > configuration parameter so that I can increase the "index to seq turn point"? :)
> >
> >
> > Thanks
> >
> >
> > OK __________________________________
> >
> > explain ANALYZE select count(1) from requisicaoanalise where
> > (ra_datacolh::date >= '2003-4-01'::date and ra_datacolh::date <
> > '2003-5-1'::date) and isactive=0;
> >
> >  Aggregate  (cost=10660.84..10660.84 rows=1 width=0) (actual
> > time=172.41..172.41 rows=1 loops=1)
> >    ->  Index Scan using requisicaoanalise_datacolh on requisicaoanalise  (cost=0.00..10654.06 rows=2711 width=0)
(actualtime=0.13..145.50 rows=9105 loops=1) 
> >          Index Cond: ((ra_datacolh >= '2003-04-01'::date) AND (ra_datacolh
> > < '2003-05-01'::date))
> >          Filter: (isactive = 0)
> >  Total runtime: 172.62 msec
> > (5 rows)
> >
> >
> >
> > NOK __________________________________
> >
> > explain ANALYZE select count(1) from requisicaoanalise where  (ra_datacolh::date >= '2003-6-01'::date and
ra_datacolh::date< '2003-7-1'::date) and isactive=0; 
> >
> > Aggregate  (cost=31019.00..31019.00 rows=1 width=0) (actual time=43252.40..43252.40 rows=1 loops=1)
> >    ->  Seq Scan on requisicaoanalise  (cost=0.00..30965.24 rows=21503 width=0) (actual time=8.43..43224.01
rows=9248loops=1) 
> >          Filter: ((ra_datacolh >= '2003-06-01'::date) AND (ra_datacolh < '2003-07-01'::date) AND (isactive = 0))
> >  Total runtime: 43252.57 msec
> > (4 rows)
> >
> >
> >
> >
> >
> > On Tue, Aug 26, 2003 at 08:37:08AM +0200, Dennis Björklund wrote:
> > > On Mon, 25 Aug 2003, Pedro Alves wrote:
> > >
> > > >     The querys below are exactly the same but refer to different months.
> > > > One case uses indexes, the other doesn't.
> > > >
> > > >     Is there anything I can do? Increasing index mem size?
> > >
> > > Run "vacuum analyze". The planner seems to think that one of the queries
> > > returns 313 rows while the other returns 2388 rows.
> > >
> > > To me that looks like the statistics need to be updated using vacuum
> > > analyze.
> > >
> > > Also, explain analyze gives a little more information and is better to
> > > run then just explain.
> > >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
> --
> Pedro Miguel G. Alves            pmalves@think.pt
> THINK - Tecnologias de Informação    www.think.pt
> Tel:   +351 21 413 46 00  Av. José Gomes Ferreira
> Fax:   +351 21 413 46 09     nº 13 1495-139 ALGÉS
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> "All that is needed for the forces of evil to triumph is for enough good
> men to do nothing." - Edmond Burke
> "The penalty good people pay for not being interested in politics is to be
> governed by people worse than themselves." - Plato

Attachment

pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: Linux ready for high-volume databases?
Next
From: Doug McNaught
Date:
Subject: Re: is linux ready for databases ? (Ziff Davis article