On Fri, Jul 2, 2021 at 12:45 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@gmail.com> writes: > > The problem is that it loops over the entire range table even though > > only one or handful of those entries actually need their permissions > > checked. Most entries, especially those of partition child tables > > have their requiredPerms set to 0, which David pointed out to me in > > [2], so what ExecCheckRTPerms() does in their case is pure overhead. > > > An idea to fix that is to store the RT indexes of the entries that > > have non-0 requiredPerms into a separate list or a bitmapset in > > PlannedStmt. > > I think perhaps we ought to be more ambitious than that, and consider > separating the list of permissions-to-check from the rtable entirely. > Your patch hardly qualifies as non-invasive, plus it seems to invite > errors of omission, while if we changed the data structure altogether > then the compiler would help find any not-updated code. > > But the main reason that this strikes me as possibly a good idea > is that I was just taking another look at the complaint in [1], > where I wrote > > >> I think it's impossible to avoid less-than-O(N^2) growth on this sort > >> of case. For example, the v2 subquery initially has RTEs for v2 itself > >> plus v1. When we flatten v1 into v2, v2 acquires the RTEs from v1, > >> namely v1 itself plus foo. Similarly, once vK-1 is pulled up into vK, > >> there are going to be order-of-K entries in vK's rtable, and that stacking > >> makes for O(N^2) work overall just in manipulating the rtable. > >> > >> We can't get rid of these rtable entries altogether, since all of them > >> represent table privilege checks that the executor will need to do. > > Perhaps, if we separated the rtable from the required-permissions data > structure, then we could avoid pulling up otherwise-useless RTEs when > flattening a view (or even better, not make the extra RTEs in the > first place??), and thus possibly avoid that exponential planning-time > growth for nested views. > > Or maybe not. But I think we should take a hard look at whether > separating these data structures could solve both of these problems > at once.
Ah, okay. I'll think about decoupling the permission checking stuff from the range table data structure. Thanks for the feedback. I'll mark the CF entry as WoA, unless you'd rather I just mark it RwF. -- Amit Langote EDB: http://www.enterprisedb.com
