Skip site navigation (1) Skip section navigation (2)

Re: selects from large tables

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 (view raw or flat)
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

In response to

pgsql-performance by date

Next:From: Rod TaylorDate: 2002-11-20 15:31:05
Subject: Re: selects from large tables
Previous:From: Tom LaneDate: 2002-11-20 15:16:42
Subject: Re: selects from large tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group