From: | Emi Lu <emilu(at)encs(dot)concordia(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: A question about Vacuum analyze |
Date: | 2006-02-16 21:24:01 |
Message-ID: | 43F4ED71.5010601@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?
Thank you,
Emi
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar | 2006-02-16 21:47:28 | Re: A question about Vacuum analyze |
Previous Message | Joshua D. Drake | 2006-02-16 21:05:06 | Re: C trigger using system(3) to execute a php script |