From: | Emi Lu <emilu(at)encs(dot)concordia(dot)ca> |
---|---|
To: | Ragnar <gnari(at)hive(dot)is> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: A question about Vacuum analyze |
Date: | 2006-02-17 17:06:26 |
Message-ID: | 43F60292.2050605@encs.concordia.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>>>>In another way, whenever we "delete/truncate and then insert" data into
>>>>a table, it is better to "vacuum anaylze"?
>>>>
>>>>
>>>>
>>>>
>>>You shouldn't need a VACUUM if you haven't yet done any updates or
>>>deletes since the TRUNCATE. An ANALYZE seems like a good idea, though.
>>>(You could get away without ANALYZE if the new data has essentially the
>>>same statistics as the old, but if you're making only minor changes, why
>>>are you using this technique at all ...)
>>>
>>>
>>>
>>>
>>After truncate table A, around 60,000 will be inserted. Then a
>>comparision will be done between table A and table B. After that, table
>>B will be updated according to the comparision result. Records inserted
>>into table A is increasing everyday.
>>
>>So, your suggestion is that after the population of table A, the query
>>planner should be able to find the most efficient query plan because we
>>do truncate but not delete, and we do not need to do vacuum analyze at
>>all, right?
>>
>>
>
>no. the suggestion was that a VACUUM is not needed, but
>that an ANALYZE might be.
>
>
Thank you gnari for your answer. But I am a bit confused about not running vacuum but only "analyze". Can I seperate these two operations? I guess "vacuum analyze" do both vacuum and analyze. Or "EXPLAIN ANALYZE" can do it for me?
Emi
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-02-17 17:08:34 | Re: A question about Vacuum analyze |
Previous Message | Joshua D. Drake | 2006-02-17 16:43:51 | Re: Btrieve to SQL |