Re: Noobie: Problems with a query
От | Chris Boget |
---|---|
Тема | Re: Noobie: Problems with a query |
Дата | |
Msg-id | 00c201c33f0d$665a8940$8c01a8c0@ENTROPY обсуждение исходный текст |
Ответ на | Noobie: Problems with a query ("Chris Boget" <chris@wild.net>) |
Ответы |
Re: Noobie: Problems with a query
|
Список | pgsql-novice |
> > > First of all you should try: VACUUM ANALYZE; > > What was that supposed to tell me? > It was supposed to make sure that the planner had reliable data from > which to plan your query. Ok. > When sending a query plan to the lists, you want to do an explain analyze > so that we can see what really happens when your query is executed as > well as what the planner thinks is going to happen. so 'EXPLAIN ANALYZE your_query' gives more information that just EXPLAIN? > The plan for your query had a fairly small number of rows for it to take > 12 seconds to run the query. This is one hint that an analyze might not > have been done. Well, I've been doing all my work through pgAdminII as it's been alot easier for me in learning. PG has alot of really obscure commands and I'm still trying to get them all down. In any case, I did 'vacuum' and 'vacuum analyze' there but neither seemed to improve matters. However, this morning, after I did 'vacuum analyze' from the PG command prompt, I re-ran the query and the rows came back in milliseconds. I'll have to see if the rows come back that quickly in pgAdmin and, if it does, that tells me there is something wrong with the way pgAdmin does the 'vacuum' and 'vacuum analyze'. If the rows don't come back that fast, then it'll tell me that there is *alot* of overhead when using pgAdmin to run queries. Thank you and Nabil for your help and suggestions. I'll report back my findings wrt pgAdminII after I get home this evening. thnx, Christoph
В списке pgsql-novice по дате отправления: