Re: pgsql: Support partition pruning at execution time
От | David Rowley |
---|---|
Тема | Re: pgsql: Support partition pruning at execution time |
Дата | |
Msg-id | CAKJS1f-FUnvjTqwf_8UvtvhRMeK6DRtS1OKqzPtq+M66aY9Y9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Support partition pruning at execution time (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-committers |
On 10 April 2018 at 09:58, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > I then noticed that support for nfiltered3 was incomplete; hence 0001. > (I then noticed that nfiltered3 was added for MERGE. It looks wrong to > me.) > > Frankly, I don't like this. I would rather have an instrument->ntuples2 > rather than these "divide this by nloops, sometimes" schizoid counters. > This is already being misused by ON CONFLICT (see "other_path" in > show_modifytable_info). But it seems like a correct fix would require > more code. +1 for a new field for this and making ON CONFLICT use it. ntuples2 seems fine. If we make it too specific then we'll end up with lots more than we need. I don't think re-using the filter counters are very good when it's not for filtering. MERGE was probably just following the example made by ON CONFLICT. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-committers по дате отправления: