On Sat, Jul 17, 2021 at 3:45 PM David Rowley wrote:
>
> On Sat, 17 Jul 2021 at 19:32, Andy Fan wrote:
> > SELECT * FROM t1, t2 WHERE t1.pk = t2.pk;
> >
> > Then when I populate_baserel_uniquekeys for t1, we already have
> > EC{Members={t1.pk, t2.pk}} in root->eq_classes already. Then I use
> > th
On Sat, 17 Jul 2021 at 19:32, Andy Fan wrote:
> SELECT * FROM t1, t2 WHERE t1.pk = t2.pk;
>
> Then when I populate_baserel_uniquekeys for t1, we already have
> EC{Members={t1.pk, t2.pk}} in root->eq_classes already. Then I use
> this EC directly for t1's UniqueKey. The result is:
>
> T1's UniqueK
On Tue, Apr 6, 2021 at 6:55 PM David Rowley wrote:
>
> On Tue, 6 Apr 2021 at 22:31, Andy Fan wrote:
> > On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat
> > wrote:
> >> I think the reason we add ECs for sort expressions is to use
> >> transitive relationship. The EC may start with a single member
On Tue, 6 Apr 2021 at 22:31, Andy Fan wrote:
> On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat
> wrote:
>> I think the reason we add ECs for sort expressions is to use
>> transitive relationship. The EC may start with a single member but
>> later in the planning that member might find partners wh
On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat
wrote:
> > b). How to present the element
> > in UniqueKey. Prue EquivalenceClasses or Mix of Expr and
> EquivalenceClass as
> > we just talked about.
> I think the reason we add ECs for sort expressions is to use
> transitive relationship. The EC
> b). How to present the element
> in UniqueKey. Prue EquivalenceClasses or Mix of Expr and EquivalenceClass as
> we just talked about.
I think the reason we add ECs for sort expressions is to use
transitive relationship. The EC may start with a single member but
later in the planning that member
On Tue, Mar 30, 2021 at 4:16 AM David Rowley wrote:
> On Tue, 30 Mar 2021 at 02:27, Ashutosh Bapat
> wrote:
> >
> > On Sat, Mar 27, 2021 at 11:44 AM Andy Fan
> wrote:
> > >
> > > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com>
> wrote:
> > >> Thanks for the patch. After a
On Tue, 30 Mar 2021 at 02:27, Ashutosh Bapat
wrote:
>
> On Sat, Mar 27, 2021 at 11:44 AM Andy Fan wrote:
> >
> > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >> Thanks for the patch. After a short look through it I'm a bit confused
> >> and wanted to clarify, now
On Sat, Mar 27, 2021 at 11:44 AM Andy Fan wrote:
>
>
>
> On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>>
>> > On Sat, Feb 20, 2021 at 10:25:59AM +0800, Andy Fan wrote:
>> >
>> > The attached is a UnqiueKey with EquivalenceClass patch, I just complete
>> > the
>> >
On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Sat, Feb 20, 2021 at 10:25:59AM +0800, Andy Fan wrote:
> >
> > The attached is a UnqiueKey with EquivalenceClass patch, I just complete
> the
> > single relation part and may have bugs. I just attached it here for
> On Sat, Feb 20, 2021 at 10:25:59AM +0800, Andy Fan wrote:
>
> The attached is a UnqiueKey with EquivalenceClass patch, I just complete the
> single relation part and may have bugs. I just attached it here for design
> review only. and the not-null-attrs is just v1 which we can continue
> discussi
Suppose we have partitioned table defined as below:
P(a, b, c, d) partition by (a)
p1 (a=1)
p2 (a=2)
p3 (a=3)
Since in PG, we can define different indexes among partitions, so each
child may
have different UniqueKeys, and some of them might be invalidated in parent's
level. For example,
12 matches
Mail list logo
