Re: Re: [RFC] [PATCH] Flexible "partition pruning" hook
От | David Steele |
---|---|
Тема | Re: Re: [RFC] [PATCH] Flexible "partition pruning" hook |
Дата | |
Msg-id | 0e0bf18c-3dfe-a716-1634-d07e299182f2@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [RFC] [PATCH] Flexible "partition pruning" hook (Mike Palmiotto <mike.palmiotto@crunchydata.com>) |
Список | pgsql-hackers |
Hi Peter, On 2/28/19 10:36 PM, Mike Palmiotto wrote: > On Wed, Feb 27, 2019 at 12:36 PM Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: >> <snip> >> To rephrase this: You have a partitioned table, and you have a RLS >> policy that hides certain rows, and you know based on your business >> logic that under certain circumstances entire partitions will be hidden, >> so they don't need to be scanned. So you want a planner hook that would >> allow you to prune those partitions manually. >> >> That sounds pretty hackish to me. We should give the planner and >> executor the appropriate information to make these decisions, like an >> additional partition constraint. > > Are you thinking of a partition pruning step for FuncExpr's or > something else? I was considering an implementation where FuncExpr's > were marked for execution-time pruning, but wanted to see if this > patch got any traction first. > >> If this information is hidden in >> user-defined functions in a way that cannot be reasoned about, who is >> enforcing these constraints and how do we know they are actually correct? > > The author of the extension which utilizes the hook would have to be > sure they use the hook correctly. This is not a new or different > concept to any other existing hook. This hook in particular would be > used by security extensions that have some understanding of the > underlying security model being implemented by RLS. Thoughts on Mike's response? Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: