Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CAKJS1f9xMOKh2gJZVQb22cfDGFKmWhuCAWqW9W04PeBbizHjkA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] path toward faster partition pruning