On 11/13/2013 06:22 AM, Torsten Förtsch wrote:
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CH
On 13/11/13 20:21, Jeff Janes wrote:
> The planner uses the check constraints to reason about the relation
> between each partition separately and the query, not between the
> different partitions. So while it may be possible to know that all rows
> in 2013_4 must be greater than all in 2013_3, it
On Wed, Nov 13, 2013 at 5:26 AM, Torsten Förtsch
wrote:
> On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
> >> My question is, why does it then try to fetch one row from every other
> >> index? Can that be avoided without a lower bound on ts?
>
> > If you don't set a lower bound, since every ot
On 11/13/2013 08:26 AM, Torsten Förtsch wrote:
On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
My question is, why does it then try to fetch one row from every other
index? Can that be avoided without a lower bound on ts?
If you don't set a lower bound, since every other table has dates bel
On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
>> My question is, why does it then try to fetch one row from every other
>> index? Can that be avoided without a lower bound on ts?
> If you don't set a lower bound, since every other table has dates below
> 2013-05-01, they have to be scanned to
On 11/13/2013 06:22 AM, Torsten Förtsch wrote:
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CH
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CHECK(ts>= '2011-1-1' and ts<'2011-1-1'::DATE + inter
On Wednesday 14 October 2009, Reid Thompson wrote:
> So we know have data in ~30 partitioned tables.
> Our requirements now necessitate adding some columns to all these tables
> ( done ) which will get populated via batch sql for the older tables and
> by normal processing as we move forward.
>
>
So we know have data in ~30 partitioned tables.
Our requirements now necessitate adding some columns to all these tables
( done ) which will get populated via batch sql for the older tables and
by normal processing as we move forward.
The batch update is going to result in dead tuples in the older
On Thu, Sep 24, 2009 at 12:02 PM, Reid Thompson wrote:
> Assuming the examples on
> http://www.postgresql.org/docs/8.3/static/ddl-partitioning.html
>
> where measurement has children as noted
>
> CREATE TABLE measurement (
> city_id int not null,
> logdate
Assuming the examples on
http://www.postgresql.org/docs/8.3/static/ddl-partitioning.html
where measurement has children as noted
CREATE TABLE measurement (
city_id int not null,
logdate date not null,
peaktempint,
11 matches
Mail list logo
