Hello,

On 09/29/2015 12:27 PM, Kyotaro HORIGUCHI wrote:
Hi,

At Sat, 26 Sep 2015 18:00:33 +0200, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote 
in <5606c121.10...@2ndquadrant.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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to