On Sun, Nov 4, 2012 at 2:32 PM, Claudio Freire wrote:
>> Well, what "partition" actually means is "only bother to try constraint
>> exclusion proofs on appendrel members". UNION ALL trees will get
>> flattened into appendrels in some cases. In a quick look at the code,
>> it seems like in recent
On Sat, Nov 3, 2012 at 10:23 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Funny thing is, if I set constraint_exclusion=on, it works as
>>> expected. But not with constraint_exclusion=partition.
>
>> The difference between "on" and "partition" is how it treats UNION.
>> This seems to be working
Josh Berkus writes:
>> Funny thing is, if I set constraint_exclusion=on, it works as
>> expected. But not with constraint_exclusion=partition.
> The difference between "on" and "partition" is how it treats UNION.
> This seems to be working as designed.
Well, what "partition" actually means is "o
> Funny thing is, if I set constraint_exclusion=on, it works as
> expected. But not with constraint_exclusion=partition.
The difference between "on" and "partition" is how it treats UNION.
This seems to be working as designed.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Se
Hi list.
I've been battling with a design issue here.
I have postgres 9.0.x deployed in some databases, and was designing
some changes that involve querying in a very partition-like way, but
not quite.
In particular, I have a few tables (lets call them table1...tableN). N
is pretty small here, b
