| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, paul rivers <rivers(dot)paul(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: postgre vs MySQL |
| Date: | 2008-03-14 17:13:03 |
| Message-ID: | 21218.1205514783@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Steve Crawford <scrawford(at)pinpointresearch(dot)com> writes:
> Alvaro Herrera wrote:
>> Of course, the main problem with CLUSTER is that it needs about 2x the
>> disk space of table + indexes.
>>
> Again checking my mental model. My understanding is that CLUSTER
> basically recreates the tables and indexes and then swaps the new ones
> in place of the originals. So ~2x is true for typical tables. But for
> tables badly bloated by multiple bulk updates or bad vacuum practices
> CLUSTER should require far less than 2x.
Another point to keep in mind is that creation of a new btree index
(and, soon, a new hash index) involves a temporary sort file that's
roughly the size of the index. So the peak transient space demand is
size of compacted table + size of compacted indexes + size of largest
index, more or less. (I suppose it'd depend on the order in which
the indexes get rebuilt.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-03-14 17:16:07 | Re: pgbench not setting scale size correctly? |
| Previous Message | Justin | 2008-03-14 17:10:21 | Re: pgbench not setting scale size correctly? |