Robert Haas writes:
> Well, on second thought, I'm no longer sure that this approach makes
> sense. I mean, it's obviously wrong for constraint-merging to change
> the validity marking on a constraint, but that does not necessarily
> imply that we shouldn't merge the constraints, does it? I see
On Fri, Jul 22, 2016 at 1:10 AM, Amit Langote
wrote:
> On 2016/07/22 0:38, Robert Haas wrote:
>> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
>> wrote:
>>> Consider a scenario where one adds a *valid* constraint on a inheritance
>>> parent which is then merged with a child table's *not valid* co
At Tue, 26 Jul 2016 13:51:53 +0900, Amit Langote
wrote in
> > So, how about splitting the original equalTupleDescs into
> > equalTupleDescs and equalTupleConstraints ?
>
> Actually TupleConstr is *part* of the TupleDesc struct, which the
> relcache.c tries to preserve in *whole* across a relca
Hello,
On 2016/07/26 11:05, Kyotaro HORIGUCHI wrote:
> At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote wrote:
>
>> So, apparently RelationClearRelation() does intend to discard a cached
>> TupleDesc if ccvalid changed in a transaction. Whereas,
>> acquire_inherited_sample_rows() does not seem
Hello,
At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote
wrote in
<96fb8bca-57f5-e5a8-9630-79d4fc5b2...@lab.ntt.co.jp>
>
> Hello,
>
> On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote:
> >
> > - Remove ccvalid condition from equalTupleDescs() to reduce
> >unnecessary cache invalidation or tup
Hello,
On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote:
>
> - Remove ccvalid condition from equalTupleDescs() to reduce
>unnecessary cache invalidation or tuple rebuilding.
The following commit introduced the ccvalid check:
"""
commit c31305de5f5a4880b0ba2f5983025ef0210a3b2a
Author: Noah Mis
Hello,
At Mon, 25 Jul 2016 15:57:00 +0900, Amit Langote
wrote in
> On 2016/07/25 12:44, Kyotaro HORIGUCHI wrote:
> > At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote:
> >> On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
> >>
> >>> By the way I have one question.
> >>>
> >>> Is it an expect
Hello,
On 2016/07/25 12:44, Kyotaro HORIGUCHI wrote:
> At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote:
>> On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
>>
>>> By the way I have one question.
>>>
>>> Is it an expected configuration where tables in an inheritance
>>> tree has different vali
Hello,
At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote
wrote in
<9733fae3-c32f-b150-e368-a8f87d546...@lab.ntt.co.jp>
> On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
> > At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote wrote:
> >> On 2016/07/22 0:38, Robert Haas wrote:
> >>> On Wed, Jul 13, 201
Hello,
On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
> At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote wrote:
>> On 2016/07/22 0:38, Robert Haas wrote:
>>> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote wrote:
Consider a scenario where one adds a *valid* constraint on a inheritance
pare
Hello,
At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote
wrote in
> On 2016/07/22 0:38, Robert Haas wrote:
> > On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
> > wrote:
> >> Consider a scenario where one adds a *valid* constraint on a inheritance
> >> parent which is then merged with a child ta
On 2016/07/22 0:38, Robert Haas wrote:
> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
> wrote:
>> Consider a scenario where one adds a *valid* constraint on a inheritance
>> parent which is then merged with a child table's *not valid* constraint
>> during inheritance recursion. If merged, the co
On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
wrote:
> Consider a scenario where one adds a *valid* constraint on a inheritance
> parent which is then merged with a child table's *not valid* constraint
> during inheritance recursion. If merged, the constraint is not checked
> for the child data e
On 7/13/16 4:22 AM, Amit Langote wrote:
Consider a scenario where one adds a *valid* constraint on a inheritance
parent which is then merged with a child table's *not valid* constraint
during inheritance recursion. If merged, the constraint is not checked
for the child data even though it may ha
Hi,
Consider a scenario where one adds a *valid* constraint on a inheritance
parent which is then merged with a child table's *not valid* constraint
during inheritance recursion. If merged, the constraint is not checked
for the child data even though it may have some. Is that an oversight?
Tha
15 matches
Mail list logo
