Re: Help on query plan. (was: select like and indexes)
От | Stephan Szabo |
---|---|
Тема | Re: Help on query plan. (was: select like and indexes) |
Дата | |
Msg-id | 20030121080118.D79963-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Help on query plan. (was: select like and indexes) ("William N. Zanatta" <william@veritel.com.br>) |
Список | 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 по дате отправления: