| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Jean-Christophe Boggio <cat(at)thefreecat(dot)org>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: vacuum analyze again... |
| Date: | 2001-02-20 19:17:51 |
| Message-ID: | 936.982696671@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> I find it hard to believe that VAC ANALYZE is all that much slower than
>> plain VACUUM anyway; fixing the indexes is the slowest part of VACUUM in
>> my experience. It would be useful to know exactly what the columns are
>> in a table where VAC ANALYZE is considered unusably slow.
> VACUUM ANALYZE does a huge number of adt/ function calls. It must be
> those calls that make ANALYZE slower. People report ANALYZE is
> certainly slower, and that is the only difference.
That's why I'm asking what the data is. The function calls per se can't
be that slow; I think there must be some datatype-specific issue.
With TOAST in the mix, TOAST fetches could very well be an issue, but
I didn't think 7.1 was being discussed ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joseph | 2001-02-20 19:19:34 | RE: postgres load |
| Previous Message | Rini Dutta | 2001-02-20 19:11:34 | RE: [SQL] handling of database size exceeding physical disk space |