| From: | Vlad Bailescu <vlad(at)mojitosoftware(dot)com> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Turning auto-analyze off (was Re: [GENERAL] Unusually high IO for autovacuum worker) |
| Date: | 2013-02-02 15:19:49 |
| Message-ID: | CABrmO8rP7b21-zQfymb7QUTioiJdoNE5Q+ipX-W_EwHdRiYtCQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 1, 2013 at 5:54 PM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>wrote:
> There is another problem that I noticed while looking at this case.
> The analyze took close to 500sec on a fairly good hardware (40GB RAM,
> 10K rpm disks on RAID10) because many large child tables were scanned
> at once.
>
Just a small correction to get a good benchmark
The ~500 sec analyze time was on a test VM running on a i5 2.4 Ghz with 2
dedicate cores, 4 GB of RAM and stored on a notebook HDD. The partitioned
data was about 80GB.
On our production environment (described by Pavan) it took ~90 second for
~55GB of data in 8 child/partition tables (we stopped the import of
partitioned data when we discovered this issue - we COPYed and TRUNCATEd
partitions to speed up upgrade procedure from 8.4 to 9.1 by
pg_dump/pg_restore).
Vlad
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-02-02 15:23:07 | Re: GetOldestXmin going backwards is dangerous after all |
| Previous Message | Bruce Momjian | 2013-02-02 15:12:54 | Re: COPY FREEZE has no warning |