On 28 December 2016 at 19:12, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >>> Hmm. I've not read any of the new code yet, but the fact that this >>> test now reduces to a one-time filter makes it effectively useless as >>> a test of qual evaluation order because it has deduced that it doesn't >>> need to evaluate them. I would suggest replacing the qual with >>> something that can't be reduced, perhaps "2*a = 6". > >> That's a good thought, I agree. > > [ getting back to this patch finally... ] I made the suggested change > to that test case, and what I see is a whole lot of "NOTICE: snooped value > = whatever" outputs. > > I'd leave it as shown in the attached diff fragment, except that I'm > a bit worried about possible platform dependency of the output. The > hashing occurring in the subplans shouldn't affect output order, but > I'm not sure if we want a test output like this or not. Thoughts? >
How about replacing "a = 3" with "a < 7 AND a != 6". That then exercises more of the possible types of behaviour for quals: The "a < 7" qual is pushed down and used as an index condition. The "a != 6" qual is pushed down and used as a filter, because it's cheap and leakproof. The leakproof() qual isn't pushed down on cost grounds. The snoop() qual isn't pushed down on security grounds. Both snoop() and leakproof() are used as filters, along with "a != 6", and a SB subplan qual. "a != 6" is executed first because it has a security_level of 0, and is cheaper than the subplan. snoop() is executed later, despite being cheaper than the other filter quals, because it has a higher security_level, and leakproof() is executed last because it has the same security level as snoop() but is more expensive. Thus the test is more likely to highlight any future changes to the pushdown/ordering rules. The output is also neater, because nothing ends up being printed by snoop(), although of course it is OK for values greater than 5 to be printed. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
