Hello, At Thu, 08 Oct 2015 15:24:35 +0200, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote in <56166e93.8000...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers