From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Jason Buberel <jason(at)altosresearch(dot)com> |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org>, "Tom Sparks (Applied Operations)" <tsparks(at)appliedops(dot)net> |
Subject: | Re: Time to move table to new tablespace |
Date: | 2012-01-10 13:50:14 |
Message-ID: | 4F0C4216.40804@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 *theoretical* solutions that use n-dimensional
partitioning of data, but Pg doesn't have automatic and
easy-to-administrate 1-dimensional partitioning, so I think going for 2D
is a bit of stretch ;-) .
I wonder how hard it'd be to extend constraint exclusion to let it use
different constraints for different queries, or even combine
constraints? The hard bit would be making it efficient. Even if the
answer is "not very", the hard bit would be maintaining a 2D (or more)
partitioned table structure. That, and making constraint exclusion
*efficient* over that many tables.
If the data being partitioned by is not only ordinal but interval too,
then it'd be possible to define regular intervals for partitioning and
build a bitmap for matching tables. That'd be a fun honours / masters
project, but hardly something suitable for trying to hack into a
production setup.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | James B. Byrne | 2012-01-10 14:17:27 | Mixed Pg-9.1.2 and 8.4.4 environment |
Previous Message | Sergey Konoplev | 2012-01-10 10:06:55 | Re: Side effects of moving an index to a new tablespace |