Re: [RFC] [PATCH] Flexible "partition pruning" hook

Поиск
Список
Период
Сортировка
От Mike Palmiotto
Тема Re: [RFC] [PATCH] Flexible "partition pruning" hook
Дата
Msg-id CAMN686GipNKvUuT98oR4d7MrwSmuu1ZYSc=obHfAN8O79eO_4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] [PATCH] Flexible "partition pruning" hook  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Re: [RFC] [PATCH] Flexible "partition pruning" hook  (David Steele <david@pgmasters.net>)
Re: [RFC] [PATCH] Flexible "partition pruning" hook  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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.

Thanks,

--
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bloom index cost model seems to be wrong
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: Question about pg_upgrade from 9.2 to X.X