As per Ondrej's suggestion, our current thinking/planning at this point is
to move indices instead of tables.
We have lots of them, they are much smaller than the tables, and that will
allow us to do the migrations more incrementally.
One area where the documentation is not very detailed - What a
On Sun, Jan 8, 2012 at 5:12 PM, Craig Ringer wrote:
> On 7/01/2012 10:52 PM, Jason Buberel wrote:
>
> I'm considering the migration of an existing large (2.3TB) table to a new
> tablespace. The table size, according to the '\dt+' command:
>
> public | ci
I'm considering the migration of an existing large (2.3TB) table to a new
tablespace. The table size, according to the '\dt+' command:
public | city_summary | table | altosresearch | 2345 GB|
Are there any considerations - besides the usual disk and network IO
constraints - that I need to ta
Pierce writes:
> > On 11/16/11 4:24 PM, Jason Buberel wrote:
> >> Just wondering if there is ever a reason to vacuum a very large table
> >> (> 1B rows) containing rows that never has rows deleted.
>
> > no updates either?
>
> To clarify: in Postgres, an "
Just wondering if there is ever a reason to vacuum a very large table (> 1B
rows) containing rows that never has rows deleted.
Under what circumstance would the table benefit from a vacuum?
-jason
--
Jason L. Buberel
CTO, Altos Research
http://www.altosresearch.com/
650.603.0907
LOL. Thats what i get for running configure and make with PG_HOME set to my
8.1.4 install.
With that fixed i will start probing my WAL archives now.
-jason
--- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: "Jason L. Buberel" <[EMAIL PROTECTED]>
Sent: 7/2/2007, 1:33:24 PM
