Re: [HACKERS] Index of a table is not used (in any case)

2001-10-25 Thread Zeugswetter Andreas SB SD
Tom Lane writes: > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: > > Imho one of the biggest sources for problems is people creating new > > indexes on populated tables when the rest of the db/table has badly > > outdated statistics or even only default statistics in place. > > In this s

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-25 Thread Tom Lane
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: > Imho one of the biggest sources for problems is people creating new > indexes on populated tables when the rest of the db/table has badly > outdated statistics or even only default statistics in place. > In this situation the optimizer is b

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-25 Thread Zeugswetter Andreas SB SD
> Of course the question "did you vacuum" (better, did you analyze) is > annoying, just as the requirement to analyze is annoying in the first > place, but unless someone designs a better query planner it > will have to do. The reason why we always ask that question first is > that people inva

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-24 Thread Peter Eisentraut
mlw writes: > The "not using index" was very frustrating to understand. The stock answer, > "did you vacuum?" just isn't enough. There has to be some explanation (in the > FAQ or something) about the indexed key distribution in your data. Most "not using index" questions seem to be related to a

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-24 Thread Tom Lane
mlw <[EMAIL PROTECTED]> writes: > ... Postgres' statistics are pretty poor too, a relative few very > populous entries in a table will make it virtually impossible for the > cost based optimizer (CBO) to use an index. Have you looked at development sources lately? regards

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-24 Thread mlw
Zeugswetter Andreas SB SD wrote: > > > > > *very* slow, due to seq scan on > > > > 20 million entries, which is a test setup up to now) > > > > > > Perennial first question: did you VACUUM ANALYZE? > > > > Can there, or could there, be a notion of "rule based" optimization of > > queries in Postg

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-24 Thread Zeugswetter Andreas SB SD
> > > *very* slow, due to seq scan on > > > 20 million entries, which is a test setup up to now) > > > > Perennial first question: did you VACUUM ANALYZE? > > Can there, or could there, be a notion of "rule based" optimization of > queries in PostgreSQL? The "not using index" problem is probably

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-23 Thread mlw
Doug McNaught wrote: > Reiner Dassing <[EMAIL PROTECTED]> writes: > > > Hello PostgreSQl Users! > > > > PostSQL V 7.1.1: > > > > I have defined a table and the necessary indices. > > But the index is not used in every SELECT. (Therefore, the selects are > > *very* slow, due to seq scan on > > 20

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-22 Thread Doug McNaught
Reiner Dassing <[EMAIL PROTECTED]> writes: > Hello PostgreSQl Users! > > PostSQL V 7.1.1: > > I have defined a table and the necessary indices. > But the index is not used in every SELECT. (Therefore, the selects are > *very* slow, due to seq scan on > 20 million entries, which is a test setup

Re: [HACKERS] Index of a table is not used (in any case)

2001-10-22 Thread Christopher Kings-Lynne
> Hello PostgreSQl Users! > > PostSQL V 7.1.1: You should upgrade to 7.1.3 at some point... > I have defined a table and the necessary indices. > But the index is not used in every SELECT. (Therefore, the selects are > *very* slow, due to seq scan on > 20 million entries, which is a test setup u

[HACKERS] Index of a table is not used (in any case)

2001-10-22 Thread Reiner Dassing
Hello PostgreSQl Users! PostSQL V 7.1.1: I have defined a table and the necessary indices. But the index is not used in every SELECT. (Therefore, the selects are *very* slow, due to seq scan on 20 million entries, which is a test setup up to now) The definitions can be seen in the annex. Does