Re: PATCH: index-only scans with partial indexes

Hello,

On 09/29/2015 12:27 PM, Kyotaro HORIGUCHI wrote:
> Hi,
>
> At Sat, 26 Sep 2015 18:00:33 +0200, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote in <5606C121(dot)10205(at)2ndquadrant(dot)com>
>> Hi,
>>
>> On 09/26/2015 01:28 PM, Tomas Vondra wrote:
>>
>>> The patch does not change the check_index_only implementation - it
>>> still needs to check the clauses, just like in v1 of the patch. To
>>> make this re-check unnecessary, we'd have to stick the remaining
>>> clauses somewhere, so that check_index_only can use only the filtered
>>> list (instead of walking through the complete list of restrictions).
>>
>> After thinking about this a bit more, I realized we already have a
>> good place for keeping this list - IndexClauseSet. So I've done that,
>
> The place looks fine but it might be better that rclauses have
> baserestrictinfo itself when indpred == NIL. It would make the
> semantics of rclauses more consistent.
>
>> and removed most of the code from check_index_only - it still needs to
>> decide whether to use the full list of restrictions (regular indexes)
>> or the filtered list (for partial indexes).
>
> The change above allows to reduce the modification still left in
> check_index_only.

I'm not sure I understand what change you suggest? Could you explain?

The change in check_index_only is effectively just (a) comment update
and (b) choice of the right list of clauses. I'd say both changes are
needed, although (b) could happen outside check_index_only (i.e. we
could do the check elsewhere). Is that what you mean?

>
> cost_index() seems to need to be fixed. It would count excluded
> clauses in estimate.

Hmm, good point. The problem is that extract_nonindex_conditions uses
baserel->baserestrictinfo again, i.e. it does not skip the implied
clauses. So we may either stick the filtered clauses somewhere (for
example in the IndexPath), teach extract_nonindex_conditions to use
predicate_implied_by. I'd say the first option is better. Agreed?

regards

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