Re: PATCH: index-only scans with partial indexes
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: index-only scans with partial indexes |
Дата | |
Msg-id | 8ad11fae-1cb7-2255-d80c-d1daafb5362f@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
Re: PATCH: index-only scans with partial indexes |
Список | pgsql-hackers |
Hi, On 03/30/2016 06:01 AM, Kyotaro HORIGUCHI wrote: > Thank you for polishing this. > > At Tue, 29 Mar 2016 13:31:19 -0500, Kevin Grittner <kgrittn@gmail.com> wrote in <CACjxUsNm9+tn0Hat0p4wR+sF0bfQDYMPLOEw7FyDycQ2UUrbyA@mail.gmail.com> >> I tried to whip this into shape, but there were a few areas I >> didn't feel I had the necessary understanding to feel comfortable >> taking on the committer role for it. I've cleaned it up the best I >> could, fixing whitespace and typos, eliminating an unnecessary >> addition of an include, improving C comments (at least to my eye), >> and adding an Assert where it seemed like a good idea to me. > > Especially for this one, > > === > @@ -2697,6 +2697,7 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel) > continue; /* don't repeat work if already proven OK */ > > have_partial = true; > + break; > } > if (!have_partial) > return; > === > > The initialization has been moved to set_rel_size so the break > can be restored. FWIW the break was restored in the v9 by me. > > >> My own tests and those of others show performance improvements (up >> to 10x for some tests) and no significant performance degradation, >> even with attempts to create "worst case" scenarios. >> >> The only changes to the regression tests are to change an "out" >> file to eliminate re-checking the index predicate against the heap >> on every matching row, which seems like a good thing. >> >> I'm taking my name off as committer and marking it "Ready for >> Committer". If someone else wants to comment on the issues where >> Tom and Kyotaro-san still seem unsatisfied to the point where I >> can get my head around it, I could maybe take it back on as >> committer -- if anyone feels that could be a net win. > > FWIW, as mentioned upthread, I added the following condition to > decline ripping index predicates from base restrictinfo without > understanding the reason to do so. Ummmm, I'm a bit confused. Which condition? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: