On Sep 30, 2014, at 8:04 PM, John R Pierce <pie...@hogranch.com> wrote: > if col_1 IS NULL, then that OR condition doesn't make much sense. just > saying...
I was just making a quick example. There are two commonly used "filter sets", each are mostly on Bool columns that allow null -- but one checks to see if the row references itself in a particular column. > these 4 columns are all nullable booleans, so they can be TRUE, FALSE, or > NULL ? Most of them, yes. > with 4 columns, there's 3^4 = 81 possible combinations of these values... > you might get better speeds encoding this as a single SHORT INTEGER, and > enumerating those 81 states, then just do equals or IN (set of values) > conditions... of course, this might make a lot of OTHER code more > complicated. It might be easier to make each col_X 2 bits of this integer, > such that one bit indicates the value was 'NULL', and the other bit is the > true/false state if that first bit isn't set, this would make testing > individual bits somewhat better. That's interesting. I never thought of how Postgres processes the data. For legacy reasons, I can't change the data types -- but I can add additional columns. So I could do a trigger/function that manages a filter_test column that is an int, give each filter a bit value, and then just run a scan on that. It wouldn't be much more work to test that and dedicated Bool columns for each filter. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
