Re: Help on query plan. (was: select like and indexes) - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Help on query plan. (was: select like and indexes)
Date
Msg-id 20030121080118.D79963-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: Help on query plan. (was: select like and indexes)  ("William N. Zanatta" <william@veritel.com.br>)
List pgsql-general
On Tue, 21 Jan 2003, William N. Zanatta wrote:

> > Okay, this shows that you are already in "C" locale, since otherwise it
> > wouldn't try it at all.  Have you done a vacuum analyze recently?
> > What does vacuum analyze verbose tbl_access; give you?
>
>    I don't remember the exactly time I did it, but I run just vacuum
> yesterday. Anyway here goes my vacuum analyze result:

Well, I was more interested in making sure that analyze was run, and the
vacuum was more to get the page/tuple information for reference.

>
> access=# vacuum analyze verbose tbl_access;
> INFO:  --Relation public.tbl_access--
> INFO:  Pages 27595: Changed 0, Empty 0; Tup 1193987: Vac 0, Keep 0,
> UnUsed 34276.
>          Total CPU 1.78s/1.68u sec elapsed 3.51 sec.
> INFO:  Analyzing public.tbl_access
> VACUUM
>


It might be a good idea to try the query Tom suggested to see what it's
thinking for the selectivity of the ip index over that range.  It's
possible that it's over estimating that portion (the 12*) which would make
sense if there are alot of 12* values or if there are a bunch of very
common values.  If it does appar to be over estimating the number of rows
that the index scan will return, you might want to try increasing the
number of statistics buckets (see alter table alter column set statistics)
to like 100 or 500 do another analyze on the table and see if that helps
the estimate any.


pgsql-general by date:

Previous
From: George.T.Essig@stls.frb.org
Date:
Subject: Re: Good (introductory) book
Next
From: Dennis Gearon
Date:
Subject: Re: Problem with alter table (creating a foreing key post facto)