Re: PATCH: index-only scans with partial indexes

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-09-17 15:40:27
Message-ID: 55FADEEB.4000907@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Horiguchi-san,

On 09/17/2015 12:45 PM, Kyotaro HORIGUCHI wrote:
>
> After all, what should be done to properly ignore useless
> conditions would be,
>
> 1. Make create_index_paths() to make the list of restrict
> clauses which are implied by the index predicate of the index
> in focus. The list would be stored as a member in
> IndexOptInfo. Then create index clauses excluding the listed
> clauses and call get_index_paths using them. Modify
> check_index_only() to ignore the listed clauses when pulling
> varattnos. This is similar but different a bit to what I said
> in the previous mail.
>
> 2. Pass the listed clauses to generated IndexPath.
>
> 3. Modify extract_nonindex_conditions to be called with the
> exclusion list and the cluases are exluded from the result of
> the function.
>
> 4. Make create_indexscan_plan to extract qpqual excluding the
> exclusion list.
>
> The same result could be obtained by more smarter way but the
> steps above will archive right decision on whether to do index
> only scan on partial index and correct cost estimate propery
> ignoring unused restrictions.
>
> Does this make sense for you?

Yes, this seems sane. I've been poking at this a bit too, and I came to
the same plan in general, except that I think it's better to build list
of clauses that are *not* implied by the index, because that's what we
need both in cost_index and check_index_only.

It also seems to me that this change (arguably a bug fix) should pretty
much make the original patch irrelevant, because check_index_only can
simply walk over the new list.

regards

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-09-17 15:55:59 Re: honour TEMP_CONFIG in pg_upgrade tests
Previous Message Alvaro Herrera 2015-09-17 15:38:44 Re: pg_resetxlog sentences