From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | kgrittn(at)ymail(dot)com, simon(at)2ndQuadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: index-only scans with partial indexes |
Date: | 2015-10-08 13:24:35 |
Message-ID: | 56166E93.8000505@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-10-08 13:47:53 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Previous Message | Amir Rohan | 2015-10-08 13:06:41 | Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files |