Re: PATCH: index-only scans with partial indexes
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: index-only scans with partial indexes |
Дата | |
Msg-id | 55FADEEB.4000907@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: PATCH: index-only scans with partial indexes (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: PATCH: index-only scans with partial indexes
|
Список | 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
В списке pgsql-hackers по дате отправления: