Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f9xMOKh2gJZVQb22cfDGFKmWhuCAWqW9W04PeBbizHjkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 4 April 2018 at 17:42, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > I'm not sure about the following change in your patch: > > - if (!result->scan_null) > - result->scan_null = step_result->scan_null; > - if (!result->scan_default) > - result->scan_default = step_result->scan_default; > + result->scan_null |= step_result->scan_null; > + result->scan_default |= step_result->scan_default; > > Afaik, |= does bitwise OR, which even if it might give the result we want, > is not a logical operation. I had written the original code using the > following definition of logical OR. > > a OR b = if a then true else b Ok, no problem. I only changed that to make it more compact. For the record we do the same in plenty of over places over the code base: E.g. parse->hasSubLinks |= subquery->hasSubLinks; /* If subquery had any RLS conditions, now main query does too */ parse->hasRowSecurity |= subquery->hasRowSecurity; -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: