| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Paul Lambert <paul(dot)lambert(at)autoledgers(dot)com(dot)au> | 
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: Vacuuming | 
| Date: | 2007-05-08 02:27:29 | 
| Message-ID: | 21713.1178591249@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Paul Lambert <paul(dot)lambert(at)autoledgers(dot)com(dot)au> writes:
> Is there any point to vacuuming a table if it has been bulk-populated by 
> data after a truncate?
> I.e. If I do this:
> TRUNCATE TABLE vehicles;
> INSERT INTO vehicles (SELECT DISTINCT ON (dealer_id,vehicle_address) * 
> FROM vehicles_temp_load WHERE (dealer_id,vehicle_address) is not null);
> Is there any point in vacuuming?
The only thing a vacuum would do for you there is set the commit hint
bits on the newly-inserted rows.  Which might be worth doing if you want
to get the table into a totally "clean" state, but it's probably a bit
excessive.  SELECTs on the table will set the hint bits anyway as
they visit not-yet-hinted rows, so it's really a matter of do you want
to pay that overhead all at once or spread-out.
What you *do* want to do in this situation is an ANALYZE.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2007-05-08 02:42:07 | Re: Date Math | 
| Previous Message | Paul Lambert | 2007-05-08 01:42:52 | Vacuuming |