From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Nikk Anderson <Nikk(dot)Anderson(at)parallel(dot)ltd(dot)uk> |
Cc: | "'Charles H(dot) Woloszynski'" <chw(at)clearmetrix(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: selects from large tables |
Date: | 2002-11-20 15:18:16 |
Message-ID: | 200211201518.gAKFIGD01247@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Nikk Anderson wrote:
> Hi,
>
> I tried a test cluster on a copy of our real data - all 10 million rows or
> so. WOW! The normal select performance improved drastically.
> Selecting 3 months worth of data was taking 146 seconds to retrieve. After
> clustering it took 7.7 seconds! We are now looking into ways we can
> automate clustering to keep the table up to date. The cluster itself took
> around 2.5 hours.
>
> As our backend systems are writing hundreds of rows of data in per minute
> into the table that needs clustering - will cluster handle locking the
> tables when dropping the old, and renaming the clustered data? What happens
> to the data being added to the table while cluster is running? Our backend
> systems may have some problems if the table does not exist when it tries to
> insert, and we don't want to lose any data.
CLUSTER will exclusively lock the table from read/write during the
CLUSTER. Sorry.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-11-20 15:31:05 | Re: selects from large tables |
Previous Message | Tom Lane | 2002-11-20 15:16:42 | Re: selects from large tables |