On 10/01/2012 3:10 AM, Jason Buberel wrote:
"Select median price for every zip code as of 2012-01-06" (customer
exports)
"Select median price for 94086 from 2005-01-01 through 2012-01-06"
(charting apps)
So by partitioning in one dimension we impact queries in the other.
Well, I know of *the
Hi,
On 10 January 2012 06:10, Jason Buberel wrote:
> "Select median price for every zip code as of 2012-01-06" (customer exports)
> "Select median price for 94086 from 2005-01-01 through 2012-01-06" (charting
> apps)
>
> So by partitioning in one dimension we impact queries in the other.
I do no
Craig,
Good suggestion - I have experimented with table partitioning in the past,
but the impact on performance was considerable.
In our case, we have one large table with real estate statistics arranged
in time (weekly for the last five years) and geography (every zip in the
US). You could imagi
Hi,
On 8 January 2012 01:52, Jason Buberel wrote:
> psql> create tablespace 'newstorage' location '/some/new/path';
> psql> alter table city_summary set tablespace = 'newstorage';
Be aware that you are not going to move indexes (see ALTER INDEX name
SET TABLESPACE tablespace_name). Maybe you don
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 | city_summary | table | altosresearch | 2345 GB|
Are there any considerations - besides the usual disk
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
