Re: How to get around LIKE inefficiencies?
От | The Hermit Hacker |
---|---|
Тема | Re: How to get around LIKE inefficiencies? |
Дата | |
Msg-id | Pine.BSF.4.21.0011060011510.928-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: How to get around LIKE inefficiencies? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: How to get around LIKE inefficiencies?
|
Список | pgsql-hackers |
On Sun, 5 Nov 2000, Bruce Momjian wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > I am adding a new TODO item: > > > * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM > > > ANALYZE, and CLUSTER > > > Seems we should be able to emit NOTICE messages suggesting performance > > > improvements. > > > > This would be targeted to help those who refuse to read documentation? > > > > I'm not following the point here... > > Well, I think there is some confusion about when CLUSTER is good, and I > can see people turning it on and running their application to look for > things they forgot, like indexes or vacuum analyze. so, we are gonna have an AI built into the database now too? my experience to date is that each scenario is different for what can be done to fix something ... as my last problem shows. I could remove the index, since it isn't used anywhere else that I'm aware of, or, as philip pointed out, I could change my query ... now, this 'PERFORMANCE_TIPS', would it have to be smart enough to think about Philips solution, or only Tom's? How is such a knowledge base maintained? Who is turned off of PgSQL when they enable that, and it doesn't help their performance even though they follow the recommendations?
В списке pgsql-hackers по дате отправления: