Hello,
At Thu, 08 Oct 2015 15:24:35 +0200, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote in
<56166E93.8000505@2ndquadrant.com>
>
>
> On 10/08/2015 07:30 AM, Kyotaro HORIGUCHI wrote:
> > Hello,
> >
> >> The attached patch applies on the latest v5 patch and will
> >> address above issues. (And modifies expected files, which are the
> >> manifestation of this improovement).
> >
> > As you see, it is a quite bad choice. Ugly and unreadable and
> > fragile.
>
> I suppose you mean placing the list into IndexClauseSet?
No, it is a reasonable choice, It's not bad if it has valid
clauses only for partial indexes. What is Ugl.. is my additional
patch:(, which let IndexClauseSet to have valid clauses.
> > The cause of this seeming mismatch would be the place to hold
> > indexrinfos. It is determined only by baserestrictinfo and
> > indpred. Any other components are not involved. So IndexClauseSet
> > is found not to be the best place after all, I suppose.
> >
> > Instead, I came to think that the better place is
> > IndexOptInfo. Partial indexes are examined in check_partial_index
> > and it seems to be the most proper place to check this so far.
>
> AFAIK there's only one IndexOptInfo instance per index, so I'm not
> sure how would that work with queries that use the index in multiple
> places?
No matter if the index is used multiple places, indexrinfos is
determined only with baserestrictinfos of the owner relation and
itself's indpred, which are invariant through the following steps.
One arguable point on the place is that check_partial_indexes
could be called again with longer restrictions (by eclass
claues), but the comment suggests that the last call will be
valid in the following steps so creating indexrinfos in every
calls should be valid.
However possibly a bit innefficient, we can choose to use the
first-created indexrinfos, which would be longer than that could
be re-created.
> Imagine for example table joined to itself, where both sides
> use the index with different conditions.
Such table appears as multiple baserels having maybe different
baserestrictinfo, so no problme on the case.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center