Re: PATCH: index-only scans with partial indexes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: PATCH: index-only scans with partial indexes
Date
Msg-id 56166E93.8000505@2ndquadrant.com
Whole thread Raw
In response to Re: PATCH: index-only scans with partial indexes  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: PATCH: index-only scans with partial indexes
List pgsql-hackers

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?

>
> 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? 
Imagine for example table joined to itself, where both sides use the 
index with different conditions.

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Amir Rohan
Date:
Subject: Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Next
From: Michael Paquier
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.