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

From Kyotaro HORIGUCHI
Subject Re: PATCH: index-only scans with partial indexes
Date
Msg-id 20160401.113949.173243164.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: PATCH: index-only scans with partial indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At Thu, 31 Mar 2016 14:51:02 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <19589.1459450262@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > Thank you for the comment. The new version is attached.
> 
> Committed with rather heavy editorialization and a batch of regression
> test cases.
> 
>             regards, tom lane

Many thanks for the editorialization (or refactoring), and many
descriptive comments and testing, then committing.

There seems no problem for me of that. The followings are my
reviw and thought on that, FWIW.


======
check_index_predicates:+ * At one time it was possible for this to get re-run after adding more+ * restrictions to the
rel,thus possibly letting us prove more indexes OK.+ * That doesn't happen any more (at least not in the core code's
usage),
!+ * but this code still supports it in case extensions want to mess with the
!+ * baserestrictinfo list.  We assume that adding more restrictions can't make+ * an index not predOK.  We must
recomputeindrestrictinfo each time, though,+ * to make sure any newly-added restrictions get into it if needed.
 

I didn't imagine that the assumption is for the sake of extensions..


+check_index_predicates(PlannerInfo *root, RelOptInfo *rel)
...
+        index->indrestrictinfo = rel->baserestrictinfo;

Ah. This has been retuened here.

+    is_target_rel = (rel->relid == root->parse->resultRelation ||
+                     get_plan_rowmark(root->rowMarks, rel->relid) != NULL);

This is very descriptive even for me.


-     * We can also discard quals that are implied by a partial index's
-     * predicate, but only in a plain SELECT; when scanning a target relation
-     * of UPDATE/DELETE/SELECT FOR UPDATE, we must leave such quals in the
-     * plan so that they'll be properly rechecked by EvalPlanQual testing.
-     *

Uggg. I'm sorry that I couldn't find this commnet just above what
I removed.

+     * way because predicate conditions need to be rechecked if the scan
+     * becomes lossy, so they have to be included in bitmapqualorig.

Of couse 'lossy' means 'may contain unqualified data', my brain
must have been in powersaving mode.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: IF (NOT) EXISTS in psql-completion